Re: Nested Transactions, Abort All

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.