"Thomas Hallgren" <[EMAIL PROTECTED]> writes:Ideally, I'd like a "beforeCompletion" that is executed prior to the start
of the commit process and a "afterCompletion" that is called when the
transaction is commited. The latter would have a status flag indicating if
status is "prepared" (to support 2-phase commits), "commited", or "rolled
back".
And what exactly would this callback do?
I imagine this would be to enforce that constraints are kept. FOREIGN KEYs can be deferred, and simple CHECK constrains can be simulated with clever foreign keys to dummy tables. Possibly allowing CHECK constraints to be deferred alleviate the need for this?
The transaction commit sequence is sufficiently delicate that I'm not interested in any proposals to call random user-written code in it. The notion of a post-commit callback is even more problematic --- what is it going to do at all? It cannot modify the database, and it cannot do anything that risks getting an error, which seems to leave mighty little scope for useful activity.
Surely this wouldn't effect the commit sequence. Post-commit actions could be just like cronjobs, but which are run as soon as there is a known need for them (and not otherwise).
Ideally triggered triggers could install pre-commit actions during the transaction. The trigger knows:
* after this particular insert/update some database logic that cannot be codified into a foreign key constraint is in an inconsistent state and must not be committed unless we are sure that some other action happened later
I've had several cases of needing sth like this, but always could hack a solution using several triggers and dummy tables that I could put into an illegal state (with a deferred foreign key). Later another trigger took that table out of the illegal state if the right action was performed.
David Helgason Over the Edge Entertainments
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
