Re: Making AFTER triggers act properly in PL functions

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.
        regards, tom lane