Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> writes:
> Hmm, if our current state of deferred triggers look like (in order)
> Trigger A
> Trigger B
> Trigger C
> and triggers A and B are made immediate and scanning begins at the
> beginning of the queue again, during the execution of the Trigger A
> trigger function, if an update is done to a table with an immediate after
> trigger (D), does the firing order look like:
> Trigger A start
> Trigger D start
> Trigger D end
> Trigger A end
> Trigger B start
> Trigger B end
Yeah, I would think so.
> What if trigger D calls set constraints to make
> Trigger C immediate?
That would be a query within D, so C would fire within D.
regards, tom lane