On Aug3, 2011, at 17:57 , Robert Haas wrote: > On Wed, Aug 3, 2011 at 4:50 AM, Florian Pflug <f...@phlo.org> wrote: >> The different between Kevin's original patch and my suggestion is, BTW, >> that he made step (7) through an error while I suggested the error to >> be thrown already at (4). > > I think Kevin's proposal is better, because AFAICS if the BEFORE > UPDATE trigger returns NULL then we haven't got a problem; and we > can't know that until we get to step 7.
Hm, not sure if I agree. A BEFORE trigger might decide to block an update, and then take some action based on the assumption that the row is actually unmodified (i.e., identical to the OLD value observed by the trigger). To me, it still seems conceptionally cleaner to just decree that a row must not be modified while BEFORE triggers are running, period. This, BTW, also matches what Oracle does, only on a per-row instead of per-table basis. Oracle AFAIR simply forbids touching of the table a BEFORE trigger is attached to from within that trigger. (They even forbid SELECTS, which is presumably because they don't have an equivalent of our per-row command id, i.e. cannot ensure that such a SELECT sees the state the table was in at the beginning of the statement) best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
