Re: BEGIN inside transaction should be an error

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: BEGIN inside transaction should be an error
Дата
Msg-id 200605180231.k4I2Vnw22119@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: BEGIN inside transaction should be an error  ("Jaime Casanova" <systemguards@gmail.com>)
Список pgsql-hackers
Added to TODO:
* Add a GUC to control whether BEGIN inside a transcation should abort  the transaction.


---------------------------------------------------------------------------

Jaime Casanova wrote:
> On 5/12/06, Mario Weilguni <mweilguni@sime.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@svana.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
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo@postgresql.org so that your
>        message can get through to the mailing list cleanly
> 

--  Bruce Momjian   http://candle.pha.pa.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


В списке pgsql-hackers по дате отправления:

Предыдущее
От: John DeSoi
Дата:
Сообщение: Re: [OT] MySQL is bad, but THIS bad?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: PL/pgSQL 'i = i + 1' Syntax