On Fri, Jul 1, 2016 at 2:12 AM, I wrote: > Currently the tuple returned by INSTEAD OF triggers on DELETEs is only > used to determine whether to pretend that the DELETE happened or not, which > is often not helpful enough; for example, the actual tuple might have been > concurrently UPDATEd by another transaction and one or more of the columns > now hold values different from those in the planSlot tuple. Attached is an > example case which is impossible to properly implement under the current > behavior. For what it's worth, the current behavior seems to be an > accident; before INSTEAD OF triggers either the tuple was already locked > (in case of BEFORE triggers) or the actual pre-DELETE version of the tuple > was fetched from the heap. > > So I'm suggesting to change this behavior and allow INSTEAD OF DELETE > triggers to modify the OLD tuple and use that for RETURNING instead of > returning the tuple in planSlot. Attached is a WIP patch implementing that. > > Is there any reason why we wouldn't want to change the current behavior?
Since nobody seems to have came up with a reason, here's a patch for that with test cases and some documentation changes. I'll also be adding this to the open commit fest, as is customary. .m
instead_of_delete_returning_v2.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
