Stephan Szabo <[EMAIL PROTECTED]> writes:
> If I'm reading the above correctly, I think DeferredTriggerSetState may
> need to change a little if EndQuery works on a separate list of triggers
> because I believe set constraints immediate currently depends on EndQuery
> going over the entire list of saved deferred triggers.
But it would. What I'm imagining is that the current list remains the
same, but it only contains trigger events from already-completed statements.
The per-query lists would be "staging areas" for gathering events from
still-active statements.
The only case where DeferredTriggerSetState would even see any nonempty
per-query list is where you had SET CONSTRAINTS being executed inside a
PL function that is called from an INSERT/UPDATE/DELETE command that has
already generated some trigger events, but is not yet complete. It is
not appropriate for those triggers to fire yet, because we haven't
completed their generating statement. When we do complete it, we'll
fire or defer the triggers according to the then-active SET CONSTRAINTS
state. So AFAICS, DeferredTriggerSetState can and should ignore open
per-query trigger lists. It will go over the whole list of events from
prior statements, though, the same as it does now.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
