Re: Feature proposal: generalizing deferred trigger events

On Wed, Jan 02, 2002 at 12:16:14PM -0500, Tom Lane wrote:

> Of course, if some other code causes a transaction
> abort, your deferred trigger will never get run, but maybe that's
> all right in your situation.

It is because I use special triggers for referential integrity checks etc..

> In your example, it would seem that you'd want the force-an-abort
> subroutine to be called at the last possible instant before we'd
> otherwise commit, so as to allow as many potential errors as possible
> to be detected and reported.  In particular, if you just throw it into
> the deferred trigger list at a random time, then only the other deferred
> triggers that are queued before it will have an opportunity to detect
> errors.  Seems like that is not really the behavior you want.

You're right, I oversimplified. I planned some ugly hacks within my
triggers to "solve" this problem. It would be better to introduce
priority levels for triggers. But this involves some deeper changes of
the implementation in `trigger.c' (not necessarily of the interface),
which I feared not to get the OK for.

If I would do so the following questions should be agreed on:

1) One trigger list for all priority levels or several lists for different  levels ?
2) A small number of priority levels or something like int16 ?

There is even a second problem with my approach: If many errors occur,
the rollback trigger is added many times to the deferred trigger
list. This is really nonsense. I can circumvent this, by holding the
xid of the last call as a static variable within the procedure adding
the rollback trigger.

-- 
Holger Krug
hkrug@rationalizer.com