Re: [HACKERS] Nested Transactions, Abort All

[Thomas Swan]

Alvaro Herrera wrote:
On Fri, Jul 02, 2004 at 01:14:25PM -0400, Merlin Moncure wrote:
 

If we change the syntax, say by using SUBCOMMIT/SUBABORT for
subtransactions, then using a simple ABORT would abort the whole
transaction tree.
     

Question: with the new syntax, would issuing a BEGIN inside a already
started transaction result in an error?
   

Yes.
 

My concern is about say, a pl/pgsql function that opened and closed a
transation.  This could result in different behaviors depending if
called from within a transaction, which is not true of the old syntax.  

Then again, since a statement is always transactionally wrapped, would
it be required to always issue SUBBEGIN if issued from within a
function?  This would address my concern.
   

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.  

I'm not trying to be argumentative, but the notation seems orthogonal to 
the issue.

Some functions and procedures may not be called inside of transactions  
or subtransactions.    Having to start with a SUBBEGIN and 
SUBCOMMIT/SUBABORT is equally problematic if you don't know where you 
begin.   Taking the extreme everything should be a SUBBEGIN and a 
SUBCOMMIT/SUBABORT so why have BEGIN and END?

Unless you have some way to tell (by query) the state you are in is a 
subtransaction and how many levels you are deep into the nested 
transaction, deciding whether to use SUBBEGIN and SUBCOMMIT/SUBABORT vs 
the traditional BEGIN COMMIT/ABORT becomes nondeterministic.


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
     subscribe-nomail command to [EMAIL PROTECTED] so that your
     message can get through to the mailing list cleanly