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 по дате отправления: