"Kevin Grittner" <kevin.gritt...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers