From: | Mike Mascari <mascarm(at)mascari(dot)com> |
---|---|
To: | Thomas Swan <tswan(at)idigx(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Nested Transactions, Abort All |
Date: | 2004-07-02 19:33:34 |
Message-ID: | 40E5B88E.3040109@mascari.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Swan wrote:
> Alvaro Herrera wrote:
>
>> Yes, I was thinking about this because the current code behaves wrong if
>> a BEGIN is issued and not inside a transaction block. So we'd need to
>> do something special in SPI -- not sure exactly what, but the effect
>> would be that the function can't issue BEGIN at all and can only issue
>> SUBBEGIN.
>>
> Isn't this counterintuitive. It seems that BEGIN and COMMIT/ABORT
> should be sufficient regardless of the level. If you are inside a
> current transaction those commands start a new transaction inside of the
> current transaction level, just like pushing on and popping off elements
> on a stack.
How about this radical idea: Use SAVEPOINT to begin a subtransaction
and ROLLBACK TO SAVEPOINT to abort that subtransaction. Normally, in
Oracle, I would write code like:
SAVEPOINT foo;
<do work>
IF (error) THEN
ROLLBACK TO SAVEPOINT foo;
END IF;
Could we not treat a subtransaction as an "anonymous" savepoint
until savepoints are added? So the above in PostgreSQL would read:
SAVEPOINT;
<do work>
IF (error) THEN
ROLLBACK TO SAVEPOINT;
END IF;
My old SQL3 draft EBNF reads:
<savepoint statement> ::= SAVEPOINT <savepoint specifier>
<savepoint specifier> ::=
<savepoint name>
| <simple target specification>
<savepoint name> ::= <identifier>
and
<rollback statement> ::=
ROLLBACK [ WORK ] [ AND[ NO ] CHAIN ]
[ <savepoint clause> ]
<savepoint clause> ::=
TO SAVEPOINT <savepoint specifier>
Mike Mascari
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2004-07-02 19:38:08 | Re: Nested Transactions, Abort All |
Previous Message | Thomas Swan | 2004-07-02 18:37:46 | Re: Nested Transactions, Abort All |