On Wed, Jan 02, 2002 at 11:31:16AM -0500, Tom Lane wrote:
> Holger Krug <hkrug@rationalizer.com> writes:
> > The proposal consists in generalizing the PostgreSQL deferred trigger
> > mechanism to more general types of events.
>
> 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.
It's not a SQL feature, but nevertheless useful in some cases, because
you can collect several errors within one transaction and are not
fobbed off with only one.
> > One use case would be a PostgreSQL procedure `mark_tx_rollback()' to
> > mark a transaction for rollback.
>
> This is unconvincing, since Postgres has no need for rollback procedures
> (and I personally will disagree with any attempt to introduce 'em; if
> you need one then you have a problem doing crash recovery).
I think you misunderstand me. `mark_tx_rollback()', when called, would
add an entry to the deferred trigger queue, which is called at commit
time *before* the transaction closes and causes transaction rollback
(and not more). All is done *within one transaction*, not after the
transaction has finished.
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.
--
Holger Krug
hkrug@rationalizer.com