Re: Nested Transactions, Abort All - Mailing list pgsql-hackers

From Oliver Jowett
Subject Re: Nested Transactions, Abort All
Date
Msg-id 40EBBB81.9030707@opencloud.com
Whole thread Raw
In response to Re: Nested Transactions, Abort All  (Dennis Bjorklund <db@zigo.dhs.org>)
Responses Re: Nested Transactions, Abort All  (Dennis Bjorklund <db@zigo.dhs.org>)
List pgsql-hackers
Dennis Bjorklund wrote:
> On Wed, 7 Jul 2004, Oliver Jowett wrote:
> 
> 
>>So how do you propose supporting simple rollback of a subtransaction? It 
>>seems like an extension regardless of how it's done.
> 
> 
> If I understand you correctly what you want is a ROLLBACK TO SAVEPOINT
> foo; followed by a RELEASE SAVEPOINT foo; 

Ugh.. nasty syntax and an extra empty transaction.

Also, how do you get an anonymous subtransaction? SAVEPOINT syntax would 
seem to always require a name.

One of the use cases for subtransactions was to avoid rollback of the 
entire transaction if there's an error in a single command -- you wrap 
each command in a subtransaction and roll it back if it fails. If we 
only have SAVEPOINT syntax this looks like:
  -- Success case  SAVEPOINT s_12345   INSERT INTO foo(...) VALUES (...)  RELEASE SAVEPOINT s_12345
  -- Error case  SAVEPOINT s_12346   INSERT INTO foo(...) VALUES (...)  ROLLBACK TO SAVEPOINT s_12346  RELEASE
SAVEPOINTs_12346
 
  -- Repeat ad nauseam

This is pretty ugly. Given that the underlying mechanism is nested 
subtransactions, why should it be necessary to jump through those sort 
of hoops to gain access to them?

If you don't like adding extra commands, what about extending the 
standard transaction control commands ("BEGIN NESTED" etc) instead?

-O


pgsql-hackers by date:

Previous
From: Dennis Bjorklund
Date:
Subject: Re: Nested Transactions, Abort All
Next
From: Dennis Bjorklund
Date:
Subject: Re: Nested Transactions, Abort All