On Tue, 7 Sep 2004, Tom Lane wrote: > Stephan Szabo <[EMAIL PROTECTED]> 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 start Trigger D start Trigger B start Trigger B end Trigger C start Trigger C end Trigger D end Trigger A end rather than: Trigger A start Trigger D start Trigger C start Trigger C end Trigger D end Trigger A end Trigger B start Trigger B end where I'd gather the latter is the intended ordering. ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
