From: | "Jaime Casanova" <systemguards(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Martijn van Oosterhout" <kleptog(at)svana(dot)org>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, "Mario Weilguni" <mweilguni(at)sime(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-11 02:43:32 |
Message-ID: | c2d9e70e0605101943k3a5fac32r73b7dc3bef430afc@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
On 5/10/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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.
>
> regards, tom lane
>
Well, actually informix throw an error... at least, my 4gl programs
always abort when a second "begin work" is found inside a
transaction...
--
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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2006-05-11 04:15:43 | Re: [COMMITTERS] pgsql: Clean up code associated with updating pg_class statistics |
Previous Message | Tom Lane | 2006-05-11 02:25:14 | Re: [GENERAL] Concurrency problem building indexes |
From | Date | Subject | |
---|---|---|---|
Next Message | Luke Lonergan | 2006-05-11 04:16:43 | Re: [PATCH] Improve EXPLAIN ANALYZE overhead by |
Previous Message | Bruce Momjian | 2006-05-11 02:08:13 | Re: [HACKERS] Question on win32 semaphore simulation |