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.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
