On Tue, Nov 19, 2013 at 01:37:56PM -0500, Bruce Momjian wrote:
> 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.
Does anyone know if this C comment justifies why ABORT is a NOTICE and
not WARNING?
/* * The user issued ABORT when not inside a transaction. Issue a * NOTICE and go to
abortstate. The upcoming call to * CommitTransactionCommand() will then put us back into the *
defaultstate. */
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +
