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@momjian.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@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +