| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Jim Nasby <jim(at)nasby(dot)net>, Joachim Wieland <joe(at)mcknight(dot)de>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: synchronized snapshots |
| Date: | 2011-08-17 01:44:56 |
| Message-ID: | 1313545496.22731.39.camel@jdavis-ux.asterdata.local |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 2011-08-16 at 20:35 -0400, Tom Lane wrote:
> I'm not convinced by the above argument, because it requires that
> you pretend there's a significant difference between syntax errors and
> "run time" errors (whatever those are).
After a syntax error like "COMMMIT" the transaction will remain inside
the failed transaction block, but an error during COMMIT (e.g. deferred
constraint check failure) will exit the transaction block.
> I think we'd be far better off to maintain the position that a failed
> BEGIN does not start a transaction, under any circumstances. To do
> that, we cannot have this new option attached to the BEGIN, which is a
> good thing anyway IMO from a standards compatibility point of view.
> It'd be better to make it a separate utility statement.
+1 for a utility statement. Much clearer from the user's standpoint what
kind of errors they might expect, and whether the session will remain in
a transaction block.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2011-08-17 01:54:44 | Re: synchronized snapshots |
| Previous Message | Robert Haas | 2011-08-17 01:10:20 | Re: Finding tables dropped by DROP TABLE CASCADE |