Re: Making AFTER triggers act properly in PL functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Making AFTER triggers act properly in PL functions
Date: 2004-09-08 13:33:47
Message-ID: 19457.1094650427@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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 ...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2004-09-08 13:54:50 Re: FYI: Fujitsu
Previous Message Hans Groschwitz 2004-09-08 12:26:15 Plannings on Implementation of DECLARE CURSOR x for SELECT ... FOR UPDATE / UPDATE ... WHERE CURRENT OF ...