Re: Nested Transactions, Abort All

From: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
To: Zeugswetter Andreas SB SD <ZeugswetterA(at)spardat(dot)at>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Nested Transactions, Abort All
Date: 2004-07-09 11:15:12
Message-ID: 40EE7E40.1020804@pse-consulting.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Zeugswetter Andreas SB SD wrote:

>>I'd opt for BEGIN as a start of a subtransaction (no need for special
>>semantics in plpgsql), the corresponding END simply changes the
>>transaction context to the parent level.
>>
>>
>
>But 'BEGIN' in plpgsql does not start a [sub]transaction, it starts a
>statement block. Are we intending to change that ? I think not.
>
>
>
There are two possibilities:
Either BEGIN *does* start a subtransaction, or BEGIN does not. I don't
see how two nesting level hierarchies in a function should be
handleable, i.e. having independent levels of statements blocks and
subtransactions.

BEGIN [whatever] suggests that there's also a statement closing that
block of [whatever], but it's very legal for subtransactions to have no
explicit end; the top level COMMIT does it all.

The SAVEPOINT semantic seems much more appropriate to describe statement
block independent transactions in this case, so if both is implemented
for SQL, savepoint only seems enough for plpgsql.

Regards,
Andreas

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Joseph Krogh 2004-07-09 12:02:05 patch for allowing multiple -t options to pg_dump
Previous Message Zeugswetter Andreas SB SD 2004-07-09 10:59:57 Re: Nested Transactions, Abort All