Re: Feature proposal: generalizing deferred trigger events

Holger Krug <hkrug@rationalizer.com> writes:
> On Wed, Jan 02, 2002 at 11:31:16AM -0500, Tom Lane wrote:
>> While I have no inherent objection to that, I'm not seeing what it's
>> good for either.  What SQL feature would be associated with this?

> The use I want to make of this feature is to collect errors during a
> transaction, report them back to the user (in my case an application
> server) and rollback the transaction when the user tries to commit.

Hmm.  So basically your code is saying "I want to abort the current
transaction, but not right now --- I can wait till the end to force
abort."  Okay.  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.

> Are there any other ways to add transaction end hooks
> (i.e. functions to be called immediately *before* the transaction
> closes) ? I would use them.

I don't think so.  I've occasionally thought that xact.c should have
a modifiable data structure instead of a hard-wired list of action
subroutines to call.  But in practice, there are usually a bunch of
constraints on the order that things must be done in, so just "add
another commit-time function call" would not be an adequate API for
adding to the list.  You'd need to be able to specify "before these
guys, after those guys" in some way.

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