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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block
Дата
Msg-id 30497.1384917707@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block  (Bruce Momjian <bruce@momjian.us>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Clang 3.3 Analyzer Results
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Turning recovery.conf into GUCs