Re: synchronized snapshots - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: synchronized snapshots
Date
Msg-id 1313545496.22731.39.camel@jdavis-ux.asterdata.local
Whole thread Raw
In response to Re: synchronized snapshots  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Finding tables dropped by DROP TABLE CASCADE
Next
From: Joe Abbate
Date:
Subject: Re: Finding tables dropped by DROP TABLE CASCADE