On Wed, Jan 02, 2002 at 11:31:16AM -0500, Tom Lane wrote:
> Holger Krug <hkrug(at)rationalizer(dot)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.
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2002-01-02 17:16:14|
|Subject: Re: Feature proposal: generalizing deferred trigger events |
|Previous:||From: Tom Lane||Date: 2002-01-02 16:41:08|
|Subject: Re: how to watch parse/plan trees |