Re: savepoint improvements - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: savepoint improvements
Date
Msg-id b42b73150701220625v4aa9c499p452aa896599f1f12@mail.gmail.com
Whole thread Raw
In response to Re: savepoint improvements  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: savepoint improvements
List pgsql-hackers
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.

In pure SQL, we have a 'begin' statement equivalent but no 'end'
statement.  Why not?

merlin


pgsql-hackers by date:

Previous
From: Michael Meskes
Date:
Subject: Re: Strange file in snapshot tarball
Next
From: "Merlin Moncure"
Date:
Subject: Re: savepoint improvements