Re: Making AFTER triggers act properly in PL functions

On Wed, 8 Sep 2004, Tom Lane wrote:

> Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> writes:
> > 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.
>
> I think it'd be very debatable which order is "intended". I don't feel
> a strong need to promise one of these orders over the other.

Okay. The former seems odd to me, especially for exception handling since
Trigger D is making Trigger C immediate, but it could receive exceptions
for Trigger B, so it couldn't assume it knows the source of the exception
(C or something done due to C's execution) if it did something like:

BEGIN
SET CONSTRAINTS C IMMEDIATE;
EXCEPTION WHEN ... THEN
...
END;

But it may not be a big deal.

> It does occur to me though that there's another hazard here: refiring
> trigger A which is already-in-progress. We'll need to add another flag
> indicating that to the trigger queue entries ...

Yeah, I thought of that after sending, but figured it was easily dealt
with.