"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> At any rate, I think we might want to apply Tom's patch for this
> while 9.3 is still early in development, to see what else might
> shake out from it while there is still plenty of time to fix any
> issues. It's now looking good from my perspective.
I just re-read the thread to refresh my memory. It seems that we pretty
much had consensus on throwing an error if any operation fired by a
BEFORE UPDATE/DELETE trigger changes the target row, unless the trigger
returns NULL to skip the update/delete. It is not clear to me however
whether we had consensus about what to do with SELECT FOR UPDATE locking
cases. The last patch posted in the thread was here:
http://archives.postgresql.org/pgsql-hackers/2012-01/msg01241.php
That message includes an example of the FOR UPDATE problem case and
says that fixing it would require significantly more work. Do we
want to worry about tackling that now, or shall we be satisfied with
fixing the trigger cases?
Also, it doesn't appear that we ever got around to preparing
documentation updates, but I think we definitely need some if we're
going to start throwing errors for things that used to be allowed.
Since Kevin has the most field experience with this problem,
I'd like to nominate him to write some docs ...
regards, tom lane
