Re: SQLExecDirectW returns SQL_SUCCESS even if sql finishes with error

Поиск
Список
Период
Сортировка
От Jonah H. Harris
Тема Re: SQLExecDirectW returns SQL_SUCCESS even if sql finishes with error
Дата
Msg-id CADUqk8V_N9pyjG3VNwWyMNpC0fqn3wML_kk1Lfa9-tB7j-Pg_Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: SQLExecDirectW returns SQL_SUCCESS even if sql finishes with error  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы RE: SQLExecDirectW returns SQL_SUCCESS even if sql finishes witherror  ("Takahashi, Ryohei" <r.takahashi_2@jp.fujitsu.com>)
Re: SQLExecDirectW returns SQL_SUCCESS even if sql finishes with error  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-odbc
On Thu, Nov 1, 2018 at 10:50 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Inoue, Hiroshi" <h-inoue@dream.email.ne.jp> writes:
> Could you please tell the customer that it's meaningless to set 
> client_min_messages to 'fatal' or 'panic'?

Yeah, I wonder why we allow that at all.  It's basically breaking
the wire protocol ...

Agreed. I'll send in a patch if you want. It appears the fatal and panic members of client_message_level_options in guc.c could be removed. The same options are similarly used by trace_recovery_messages, but that seems to make sense even in that regard. Likewise, postgresql.conf.sample only shows debug5-error as options; omitting fatal and panic. The web docs, however, show fatal and panic as options.

Thoughts?

--
Jonah H. Harris

В списке pgsql-odbc по дате отправления:

Предыдущее
От: "Tobias Wendorff"
Дата:
Сообщение: Re: NUMERIC type makes trouble in MS Access
Следующее
От: "Inoue, Hiroshi"
Дата:
Сообщение: Re: NUMERIC type makes trouble in MS Access