Tom Lane <t...@sss.pgh.pa.us> wrote: > "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? As you said in the referenced message, the FOR UPDATE issue seems orthogonal and should probably be addressed separately. > 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 ... OK, will do. The "redo the DELETE and RETURN NULL" workaround is not at all obvious; we should definitely include an example of that. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers