Tom Lane wrote: > Stefan Kaltenbrunner <ste...@kaltenbrunner.cc> writes: > > the "surprise" here was that the delete is getting silently surpressed > > even though the original Qual still holds and afaik should result in the > > row deleted. > > The delete from foo acts first (since you put it in a BEFORE trigger). > After the trigger comes back, the outer delete finds itself trying > to delete a row that was already updated by a later-starting command in > the same transaction.
Hmm, I misread the code when talking to Stefan on IM. I followed the path that heap_update returns HeapTupleUpdated, which proceeds to do EvalPlanQual and attempt to update the updated version of the row. However I'm guessing that what actually happens is that heap_update is returning HeapTupleSelfUpdated instead, which the code states as /* nothing to do */. I imagine this is so because of some old fiddling to get semantics just right for obscure corner cases, but it feels wrong nevertheless. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
