Re: Nested Transactions, Abort All - Mailing list pgsql-hackers

From Zeugswetter Andreas SB SD
Subject Re: Nested Transactions, Abort All
Date
Msg-id 46C15C39FEB2C44BA555E356FBCD6FA40184D142@m0114.s-mxs.net
Whole thread Raw
In response to Nested Transactions, Abort All  (Thomas Swan <tswan@idigx.com>)
Responses Re: Nested Transactions, Abort All  (Pavel Stehule <stehule@kix.fsv.cvut.cz>)
List 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


pgsql-hackers by date:

Previous
From: Yannick Lecaillez
Date:
Subject: Re: SAN, clustering, MPI, Backplane Re: Postgresql on
Next
From: "Marc G. Fournier"
Date:
Subject: Re: User Quota Implementation