Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block

On Tue, Nov 19, 2013 at 10:21:47PM -0500, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > 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 abort state. The upcoming call to
> > * CommitTransactionCommand() will then put us back into the
> > * default state.
> > */
>
> It's just describing the implementation, not defending the design choice.
>
> My personal standpoint is that I don't care much whether these messages
> are NOTICE or WARNING. What I'm not happy about is promoting cases that
> have been non-error conditions for years into ERRORs.

I don't remember any cases where that was suggested.

> Now, if we wanted to go the other way (downgrade some ERRORs to WARNINGs),
> that would not create an application compatibility problem in my view.

Yes, that was my initial plan, but many didn't like it.

> And on the third hand, there's Emerson's excellent advice: "A foolish
> consistency is the hobgoblin of little minds". I'm not convinced that
> trying to make all these cases have the same message level is actually
> a good goal. It seems entirely plausible that some are more dangerous
> than others.

The attached patch changes ABORT from NOTICE to WARNING, and documents
that all other are errors. This "top-level" logic idea came from Robert
Haas, and it has some level of consistency.

Interesting that ABORT was already documented as returning a warning:

Issuing <command>ABORT</> when not inside a transaction does
no harm, but it will provoke a warning message.
-------

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +