Re: [PATCH] SQL function to report log message

Hi All,

On Tue, Oct 20, 2015 at 1:22 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
wrote:

>
> 2015-10-20 20:05 GMT+02:00 Robert Haas <robertmhaas(at)gmail(dot)com>:
>
>> On Tue, Oct 20, 2015 at 11:29 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
>> wrote:
>> > 2015-10-20 17:15 GMT+02:00 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> >> On Tue, Oct 20, 2015 at 11:09 AM, Pavel Stehule <
>> pavel(dot)stehule(at)gmail(dot)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.
>
>
Thanks for valuable insight inputs.

I just want to be clear about the things from your side,
and want to take further required development from my side.

Let me summarize the issues as below.

1. We need a patch, as per Jim's suggestion about RAISE's USING
should skip any NULL argument, rather throwing an ERROR.
So, we need a new patch if everyone accept this for the RAISE statement.

2. Using this function, if we provide any "NULL" argument to the function,
we should either skip it or report it. I see this is what the function is
doing.

postgres=# SELECT pg_report_log('INFO', 'NULL', false, NULL, NULL);
INFO: NULL

postgres=# SELECT pg_report_log('INFO', 'NULL', false, 'NULL', 'NULL');
INFO: NULL
DETAIL: NULL *-- Are you suggesting to change this behaviour*
HINT: NULL

Kindly let me know your suggestions. Please find the attached patch, which
is generated on top of latest branch head.

Thanks in advance.

--

Regards,
Dinesh
manojadinesh.blogspot.com