Stefan Kaltenbrunner <stefan@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. So it doesn't do anything to that row (cf the
HeapTupleSelfUpdated cases in execMain.c). I think this is documented
someplace but don't remember where.
regards, tom lane
