Tom Lane wrote: > Heikki Linnakangas <[EMAIL PROTECTED]> writes: >> I'm not sure what to do about this. We could change the order the >> triggers are fired to breadth-first. If all the setnull triggers were >> executed first, there would be no problem. But that seems like a pretty >> big change, and I'm afraid it might have other unintended consequences. > > I think it's not so much that they should be "breadth first" as that the > updates generated by the triggers shouldn't count as their own > sub-statements. The trigger events generated by those updates need to > go at the end of the outer statement's trigger queue. We'll need to > change the API of SPI_execute_snapshot for this, but since that's only > for the use of the RI triggers anyway, it doesn't seem like a problem. > > I also notice that only one of the > afterTriggerMarkEvents/afterTriggerInvokeEvents pairs in trigger.c > is coded as a "while" ... they probably all must be if we expect that RI > triggers will generate events at the same trigger level.
I can take a stab at writing a patch. Does this need to be backported? It's a bug, but I feel uncomfortable backporting. I'm afraid it'll break some other corner cases, and it doesn't seem to be a huge problem in practice since no-one's ran into it until now. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
