Re: TODO: Add a GUC to control whether BEGIN inside

Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> Am Donnerstag, 28. Dezember 2006 18:57 schrieb Bruce Momjian:
>>> I think you can make the case that this should be an error, or at least
>>> that's how it got on the TODO list.  I can always remove it if people
>>> don't want the item completed.
> 
>> The reason this was added is that modular applications expect that a locally 
>> issued BEGIN ... COMMIT executes a transaction, whereas now you don't know 
>> what you're getting.  I think this change would have merit.
> 
> But how is making BEGIN an error going to improve life for such an
> application?  It'll be just as broken.  In fact, if the app depends on
> getting an error from BEGIN in any critical way, it'll be *more* broken
> if it's ever run under the default warning-only setting.

While we are on the topic, I have implemented a poor mans nested 
transaction feature into my database access layer. essentially 
subsequent calls to begin a transaction after the initial begin simply 
increase an internal counter and set a savepoint. as you commit the 
transactions the counter is decreased and the savepoints are released. 
maybe this could be implemented inside postgresql to make the life of 
modular programmers easier?

regards,
Lukas