On Wed, Nov 22, 2023 at 1:13 PM Bruce Momjian <br...@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
