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
