Hi, I'm new to this list.
Having got some insight into the PostgreSQL sources by following
server action using GDB and after trying to implement some features I
became able to formulate a proposal which IMHO could be useful for
others, too.
The proposal consists in generalizing the PostgreSQL deferred trigger
mechanism to more general types of events. Such an event could be,
e.g., a function call deferred up to transaction end.
One use case would be a PostgreSQL procedure `mark_tx_rollback()' to
mark a transaction for rollback. The rollback will be performed at
transaction commit time. (Actually `mark_tx_rollback()' can be
implemented by faking a `ResultRelInfo' and calling
`ExecARInsertTriggers' or similar functions with the faked
`ResultRelInfo' but this is not the cleanest way and will not work for
other use cases.)
The implementation would be straightforward, changes have to be made
only to `trigger.c' and `trigger.h'. A data structure
`DeferredEventData' must be added, from which as well the existing
`DeferredTriggerEventData' as also `DeferredFunctionCallEvent' will be
derived. The implementation of `deferredTriggerInvokeEvents(bool)'
must be changed to separate DeferredTriggerEvent's from
DeferredFunctionCallEvent's. A function `DeferredFunctionCallExecute'
called from `deferredTriggerInvokeEvents(bool)' in the case of a
`DeferredFunctionCallEvent' and functions to add
DeferredFunctionCallEvent's to the queue have to be added.
I would be able to make the necessary changes and post the patch (to
whom ?). Is it OK ? Are there others working on similar or
contradicting features ? Does my proposal conform to the further plans
of PostgreSQL development ?
--
Holger Krug
hkrug@rationalizer.com
