"Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)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
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2001-10-01 21:38:27|
|Subject: Re: HISTORY file|
|Previous:||From: Mikheev, Vadim||Date: 2001-10-01 21:25:41|
|Subject: Re: Bulkloading using COPY - ignore duplicates? |