Re: Nested Transactions, Abort All

From: "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at>
To: "Andreas Pflug" <pgadmin(at)pse-consulting(dot)de>
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 13:54:07
Message-ID: 46C15C39FEB2C44BA555E356FBCD6FA40184D142@m0114.s-mxs.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> >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.

An 'END SUB' after a 'BEGIN SUB' in plpgsql could be required, and could
mean start/end block and subtx. I do not really see a downside.
But, it would imho only make sense if the 'END SUB' would commit sub
or abort sub iff subtx is in aborted state (see my prev posting)

Andreas

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marc G. Fournier 2004-07-09 14:04:00 Re: User Quota Implementation
Previous Message Stephen Frost 2004-07-09 13:29:14 Re: User Quota Implementation