On Wed, Nov 22, 2023 at 1:13 PM Bruce Momjian <bruce@momjian.us> wrote:
> I think I found out what it trying to say by looking at the INSERT
> manual page:
>
> Note that the effects of all per-row <literal>BEFORE
> INSERT</literal> triggers are reflected in
> <varname>excluded</varname> values, since those effects may
> have contributed to the row being excluded from insertion.
>
> I modified the attached patch to explain this since it is not really the
> same as modifying the actual row. Does that add any value? If not,
> let's remove it.
I don't understand where the confusion lies.
EXCLUDED.* is literally the row that we tried and failed to insert,
which quite naturally carries the effects of BEFORE ROW triggers. This
seems like the only behavior that makes any sense to me, even if it
can lead to confusing outcomes at times. It comes with an obvious
problem: EXCLUDED.* might not exactly match the row originally
proposed for insertion by the INSERT statement. This kind of confusion
can happen even when the table only has INSERT-type BEFORE ROW
triggers, though -- cases involving a mix of INSERT and UPDATE row
triggers are just a more elaborate version of the same confusion.
I don't think that your proposed wording for this is an improvement.
In particular, "it is possible for both row-level BEFORE INSERT and
BEFORE UPDATE triggers to be executed on the same row" leaves me
wondering what "the same row" refers to. Is it the row as it was prior
to the BEFORE triggers ran, after they ran, or something else? Or is
it more like the execution context of a single row?
--
Peter Geoghegan