From: | Mario Weilguni <mweilguni(at)sime(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | 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 07:16:44 |
Message-ID: | 200605120916.44495.mweilguni@sime.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
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.
regards
mario weilguni
From | Date | Subject | |
---|---|---|---|
Next Message | Matteo Beccati | 2006-05-12 08:02:08 | Re: [HACKERS] Enhanced containment selectivity function |
Previous Message | Qingqing Zhou | 2006-05-12 06:58:58 | Re: Need some clarification |
From | Date | Subject | |
---|---|---|---|
Next Message | Matteo Beccati | 2006-05-12 08:02:08 | Re: [HACKERS] Enhanced containment selectivity function |
Previous Message | Jim C. Nasby | 2006-05-11 23:37:03 | Re: [PATCH] Improve EXPLAIN ANALYZE overhead by sampling |