Re: savepoint improvements - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: savepoint improvements
Date
Msg-id 1169478155.3776.304.camel@silverbirch.site
Whole thread Raw
In response to Re: savepoint improvements  ("Merlin Moncure" <mmoncure@gmail.com>)
Responses Re: savepoint improvements  ("Merlin Moncure" <mmoncure@gmail.com>)
List pgsql-hackers
On Mon, 2007-01-22 at 09:25 -0500, Merlin Moncure wrote:
> On 1/21/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > "Jaime Casanova" <systemguards@gmail.com> writes:
> > > On 1/21/07, Simon Riggs <simon@2ndquadrant.com> wrote:
> > >> - continue on error i.e. COMMIT can/might succeed - though there are
> > >> still cases where it cannot, such as a serializable exception.
> >
> > > and what should be the behaviour of that? the same as rollback?
> >
> > The only conceivable implementation is an implicit savepoint issued
> > before each statement.
> 
> I'm not sure I agree here...before the NT implementation was changed
> over to savepoint syntax it was perfectly possible to recover from
> errors inside a  transaction...and is still possible in plpgsql
> functions only.  What I'm asking for is to reopen this behavior
> somehow...in the production environments I've worked in application
> update and maintenance relied heavily on scripting, and lack of this
> functionality forces me to wrap the script launch with C code to work
> around limitations of the savepoint system.

Could you post an example, just so we're all clear what the problems
are? I thought I understood what you are requesting; I may not.

--  Simon Riggs              EnterpriseDB   http://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Piggybacking vacuum I/O
Next
From: Bruce Momjian
Date:
Subject: Re: [GENERAL] Autovacuum Improvements