| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
| Cc: | "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 01:24:11 |
| Message-ID: | 25861.1147310651@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-05-11 01:34:38 | Re: .pgpass file and unix domain sockets |
| Previous Message | Tom Lane | 2006-05-11 00:31:54 | Re: [HACKERS] Big IN() clauses etc : feature proposal |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Qingqing Zhou | 2006-05-11 01:38:00 | Re: [HACKERS] Question on win32 semaphore simulation |
| Previous Message | Martijn van Oosterhout | 2006-05-10 21:26:08 | Re: BEGIN inside transaction should be an error |