Re: BEGIN inside transaction should be an error

From: "Jaime Casanova" <systemguards(at)gmail(dot)com>
To: "Mario Weilguni" <mweilguni(at)sime(dot)com>
Cc: "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Martijn van Oosterhout" <kleptog(at)svana(dot)org>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, pgsql-hackers(at)postgresql(dot)org, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "Dennis Bjorklund" <db(at)zigo(dot)dhs(dot)org>
Subject: Re: BEGIN inside transaction should be an error
Date: 2006-05-12 13:00:13
Message-ID: c2d9e70e0605120600k3fdd001aua723557338528191@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

On 5/12/06, Mario Weilguni <mweilguni(at)sime(dot)com> wrote:
> Am Donnerstag, 11. Mai 2006 22:16 schrieb Simon Riggs:
> > On Wed, 2006-05-10 at 21:24 -0400, Tom Lane wrote:
> > > Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> > > > 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?
> > >
> > > Probably not. The SQL99 spec does say (in describing START TRANSACTION,
> > > which is the standard spelling of BEGIN)
> > >
> > > 1) If a <start transaction statement> statement is executed when
> > > an SQL-transaction is currently active, then an exception condition is
> > > raised: invalid transaction state - active SQL-transaction.
> > >
> > > *However*, they are almost certainly expecting that that condition only
> > > causes the START command to be ignored; not that it should bounce the
> > > whole transaction. So I think the argument that this is required by
> > > the spec is a bit off base.
> >
> > If you interpret the standard that way then the correct behaviour in the
> > face of *any* exception condition should be *not* abort the transaction.
> > In PostgreSQL, all exception conditions do abort the transaction, so why
> > not this one? Why would we special-case this?
>
> IMO it's ok to raise an exception - if this is configurable for at least one
> releasy cycle - giving developers time to fix applications. It's no good
> behaviour to change something like this without any (at least time-limited )
> backward compatible option.
>

if an option to change it is put in place, maybe it will be there
forever (with a different default behavior)...

i am all in favor of a second begin to throw an exception "already in
transaction" or something else
(http://archives.postgresql.org/pgsql-hackers/2005-12/msg00813.php),
but if we do it we should do it the only behavior... i don't think
it's good to introduce a new GUC for that things (we will finish with
GUCs to turn off every fix)

--
regards,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-05-12 13:33:45 Re: [HACKERS] Enhanced containment selectivity function
Previous Message Dave Page 2006-05-12 12:29:01 Re: Clarification required

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2006-05-12 13:33:45 Re: [HACKERS] Enhanced containment selectivity function
Previous Message Simon Riggs 2006-05-12 10:46:38 Re: [PATCH] Improve EXPLAIN ANALYZE overhead by sampling