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

2015-10-20 20:05 GMT+02:00 Robert Haas <robertmhaas@gmail.com>:

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?

My previous idea was wrong (I didn't though well about all details). I am sorry. The implementation of variadic parameters in Postgres requires some default value - in this case the only one logical default value is NULL. And in this case, when the default is used, the NULL shouldn't be displayed. I propose following behave. The level and the message arguments are mandatory (has not default value), others are optional. The level is should not be NULL, the message can be NULL, and the NULL should be displayed, any others are ignored if holds NULL.  A alternative is - only the level will be mandatory, others will be optional, and then there are not any exception for message.