Re: [PATCH] SQL function to report log message - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [PATCH] SQL function to report log message
Date
Msg-id CA+TgmobRbs1u8O9O2=N9NNmRAA-q7NAYtc2oQ-pD+QjDOq8QGg@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] SQL function to report log message  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: [PATCH] SQL function to report log message  (Pavel Stehule <pavel.stehule@gmail.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Dangling Client Backend Process
Next
From: Alvaro Herrera
Date:
Subject: Re: Dangling Client Backend Process