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

From Tom Lane
Subject Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block
Date
Msg-id 30497.1384917707@sss.pgh.pa.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
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.

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.

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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Clang 3.3 Analyzer Results
Next
From: Tom Lane
Date:
Subject: Re: Turning recovery.conf into GUCs