> The effects don't stop propagating there, either. The decision
> not to insert the tuple must be reported up still further, so
> that the executor knows not to run any AFTER INSERT/UPDATE
> triggers and knows not to count the tuple as inserted/updated
> for the command completion report.

But what about BEFORE insert/update triggers which could insert
records too?

Vadim

Mon, 1 Oct 2001 14:25:41 -0700 
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
Re: Bulkloading using COPY - ignore duplicates? 
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
>> The effects don't stop propagating there, either. The decision
>> not to insert the tuple must be reported up still further, so
>> that the executor knows not to run any AFTER INSERT/UPDATE
>> triggers and knows not to count the tuple as inserted/updated
>> for the command completion report.

> But what about BEFORE insert/update triggers which could insert
> records too?

Well, what about them?  It's already possible for a later BEFORE trigger
to cause the actual insertion to be suppressed, so I don't see any
difference from what we have now.  If a BEFORE trigger takes actions
on the assumption that the insert will happen, it's busted already.


Mind you, I'm not actually advocating that we do any of this ;-).
I was just sketching a possible implementation approach in case someone
wants to try it.

			regards, tom lane

Mon, 01 Oct 2001 17:38:24 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Bulkloading using COPY - ignore duplicates? 