Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
