On Tue, 7 Sep 2004, Tom Lane wrote:
> Stephan Szabo <sszabo@megazone.bigpanda.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.
Right, but if we search the entire trigger queue from the beginning
looking for all triggers now immediate and fire them in the EndQuery of
the set constraints statement contained in D, we'd potentially get an
ordering like:
Trigger A startTrigger D start Trigger B start Trigger B end Trigger C start Trigger C endTrigger D end
Trigger A end
rather than:
Trigger A startTrigger D start Trigger C start Trigger C endTrigger D end
Trigger A end
Trigger B start
Trigger B end
where I'd gather the latter is the intended ordering.
