Re: [PATCH] SQL function to report log message
| От | Pavel Stehule |
|---|---|
| Тема | Re: [PATCH] SQL function to report log message |
| Дата | |
| Msg-id | CAFj8pRAgjhHbW-p=BaPZ-OCqXxJmS7u8p3HQ=dMp3pd8tJhqnQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [PATCH] SQL function to report log message (Peter Eisentraut <peter_e@gmx.net>) |
| Ответы |
Re: [PATCH] SQL function to report log message
|
| Список | pgsql-hackers |
Hi
2015-10-22 22:03 GMT+02:00 Peter Eisentraut <peter_e@gmx.net>:
On 10/22/15 3:20 AM, dinesh kumar wrote:
> 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
These look wrong to me.
I'd throw an error if a null message is passed.
(Not particularly in favor of this patch, but just saying ...)
We talked about this behave - and in this case, I am thinking the any fields with same value with default value should be ignored.
the behave of pg_report_log should not be exactly same as RAISE statement in PLpgSQL. If this function will be exactly same, then it lost a sense and anybody can use RAISE statement. RAISE statement is strict - in this moment to strict (can be little bit less), and pg_report_log can be NULL tolerant. It is limmited by our implementation of keyword parameters that needs some default value.
Regards
Pavel
В списке pgsql-hackers по дате отправления: