Re: BEGIN inside transaction should be an error - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: BEGIN inside transaction should be an error
Date
Msg-id 20060510212608.GC14476@svana.org
Whole thread Raw
In response to Re: BEGIN inside transaction should be an error  ("Jim C. Nasby" <jnasby@pervasive.com>)
Responses Re: BEGIN inside transaction should be an error
Re: BEGIN inside transaction should be an error
List pgsql-hackers
On Wed, May 10, 2006 at 04:03:51PM -0500, Jim C. Nasby wrote:
> On Wed, May 10, 2006 at 12:31:52PM +0200, Mario Weilguni wrote:
> > Maybe. I just want to emphasize that it will break existing applications.
>
> If the existing application is trying to start a new transaction from
> within an existing one, I'd say it's already broken and we're just
> hiding that fact.

Well maybe, except the extra BEGIN is harmless. I'm thinking of the
situation where a connection library sends a BEGIN on startup because
it wants to emulate a non-autocommit mode. The application then
proceeds to handle transactions itself, sending another BEGIN and going
from there.

We'll have just broken this perfectly working application because it
failed the purity test. The backward compatability issues are huge and
it doesn't actually bring any benefits.

How do other database deal with this? Either they nest BEGIN/COMMIT or
they probably throw an error without aborting the transaction, which is
pretty much what we do. Is there a database that actually aborts a
whole transaction just for an extraneous begin?

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [TODO] Allow commenting of variables ...
Next
From: "Jim C. Nasby"
Date:
Subject: Re: sblock state on FreeBSD 6.1