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.
