Re: [PATCH] SQL function to report log message

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [PATCH] SQL function to report log message
Дата
Msg-id CA+TgmobRbs1u8O9O2=N9NNmRAA-q7NAYtc2oQ-pD+QjDOq8QGg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] SQL function to report log message  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: [PATCH] SQL function to report log message  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
On Tue, Oct 20, 2015 at 11:29 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> 2015-10-20 17:15 GMT+02:00 Robert Haas <robertmhaas@gmail.com>:
>> On Tue, Oct 20, 2015 at 11:09 AM, Pavel Stehule <pavel.stehule@gmail.com>
>> wrote:
>> > Probably it was my request. I don't like to using NULL as value, that
>> > should
>> > be ignored. The "hint" is clean, there NULL can be ignored, but what
>> > about
>> > DETAIL or MESSAGE?
>>
>> If the field is required - as MESSAGE is - then its absence is an
>> error.  If the field is optional, treat a NULL if the parameter were
>> not supplied.
>
> I understand well, what was proposed. Personally I see small risk, but I am
> thinking so can be useful if users can choose between two possibilities
> (strict, and NULL tolerant). For some adhoc work it can be useful.

You haven't made any attempt to explain why that behavior would be
useful to anyone except that saying some information might be lost.
But what field of an error report can sensibly be populated with the
word NULL, and nothing else?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Dangling Client Backend Process
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Dangling Client Backend Process