On Aug8, 2011, at 17:02 , Kevin Grittner wrote: > So, we have three options on the table here: > > (1) We (the Wisconsin Courts) are using a very simple fix to work > around the issue so we can move forward with conversion to > PostgreSQL triggers. A DELETE is allowed to complete if the BEFORE > trigger doesn't return NULL, even if the row was updated while the > trigger was executing. An UPDATE fails if the BEFORE trigger > doesn't return NULL and any other update is made to the row while > the trigger was executing. > > (2) You (Robert) have proposed (as I understand it) modifying that > approach to allow some UPDATE cases to work, where there are not > conflicting updates to any one column within the row. > > (3) Florian has proposed banning all updates to a row which is being > processed by a BEFORE UPDATE or BEFORE DELETE trigger. As I > understand it, this would be similar to the approach taken by > Oracle, although less strict. Yeah, though much, much less strict.
I think it would be helpful if we had a more precise idea about the intended use-cases. So far, the only use-case that has been described in detail is the one which made Kevin aware of the problem. But if I understood Kevin correctly, that fact that they use BEFORE and not AFTER triggers it more of an accident than the result of a conscious design decision. Though he did also mention that there might actually be advantages to using BEFORE instead of AFTER triggers, because that prevents other triggers from seeing a non-consistent state. What I can add is that AFAIR all instances of same-row UPDATES from BEFORE triggers I ever encountered where replaceable by a simple assignment to NEW. (That, however, is more of an anti-usecase) 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
