Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block
Date
Msg-id 20131119183756.GT28149@momjian.us
Whole thread Raw
In response to Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Tue, Nov 19, 2013 at 01:31:55PM -0500, Bruce Momjian wrote:
> On Tue, Nov 19, 2013 at 01:20:47PM -0500, Robert Haas wrote:
> > I think the pattern is and should be different for toplevel
> > transaction control commands than for other things.  If you issue a
> > BEGIN, we want it to end up that you're definitely in a transaction at
> > that point, and if you issue a COMMIT or ROLLBACK or ABORT, we want
> > you to definitely be out of a transaction after that.  This is
> > important for reasons discussed on Andrew's thread about pre-commit
> > triggers just today.
> > 
> > The same considerations don't apply elsewhere; the user has made a
> > mistake, and there's no particular reason not to throw an ERROR.  We
> > could throw a WARNING or NOTICE and pretend like things are OK, but
> > there doesn't seem to be much point, certainly not enough to justify
> > changing long-established behavior.
> 
> OK, what I am hearing you say is that we should change ABORT from NOTICE
> to WARNING, leave SAVEPOINT/ROLLBACK TO SAVEPOINT as WARNING (so all
> transaction control commands are warnings), and leave the new SET
> commands as ERRORs.  Works for me.

Sorry, even I am getting confused.  SAVEPOINT/ROLLBACK TO SAVEPOINT stay
as ERROR, so effectively only top-level transaction control commands
BEGIN WORK/ABORT/COMMIT are WARNINGS.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1
Next
From: Andres Freund
Date:
Subject: Re: Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1