Re: Making AFTER triggers act properly in PL functions
| От | Tom Lane |
|---|---|
| Тема | Re: Making AFTER triggers act properly in PL functions |
| Дата | |
| Msg-id | 19457.1094650427@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Making AFTER triggers act properly in PL functions (Stephan Szabo <sszabo@megazone.bigpanda.com>) |
| Ответы |
Re: Making AFTER triggers act properly in PL functions
|
| Список | pgsql-hackers |
Stephan Szabo <sszabo@megazone.bigpanda.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
В списке pgsql-hackers по дате отправления: