Re: savepoint improvements

From: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Jaime Casanova" <systemguards(at)gmail(dot)com>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: savepoint improvements
Date: 2007-01-22 14:25:35
Message-ID: b42b73150701220625v4aa9c499p452aa896599f1f12@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 1/21/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Jaime Casanova" <systemguards(at)gmail(dot)com> writes:
> > On 1/21/07, Simon Riggs <simon(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2007-01-22 14:40:45 Re: savepoint improvements
Previous Message Simon Riggs 2007-01-22 13:06:53 Re: [PATCHES] pg_standby