Since this is a rather larger patch than we customarily apply during beta, I thought I'd better circulate it for review before pushing it in.
It is not ready to apply yet because it lacks regression tests or doc updates, and also I haven't yet done anything about the idea of saving space by sharing information across many firings of the same trigger. But it addresses the basic problem of firing AFTER triggers at the "right times" within functions. And I think it offers a reasonable approach to the issues Stephan raised about what happens when a trigger function mucks with the firing order by executing SET CONSTRAINTS. In this implementation, any particular query determines the set of pending triggers it will fire before any of them are actually executed. A SET CONSTRAINTS within one of those triggers cannot alter the scheduling of any already-scheduled-to-fire trigger, but it can enable and execute triggers that the outer query has determined it will not fire. I also took the liberty of renaming structs and functions in the interests of clarity. In particular, all the "DeferredTrigger" stuff is now "AfterTrigger" stuff, since it actually handles all AFTER triggers whether they are "deferred" in the spec's sense or not. Comments, objections, better ideas? I hope to commit this in the next couple days. regards, tom lane
binG1qP6B39iq.bin
Description: trigger.patch.gz
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]