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
