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. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster