Re: [PATCH] SQL function to report log message
| От | Pavel Stehule |
|---|---|
| Тема | Re: [PATCH] SQL function to report log message |
| Дата | |
| Msg-id | CAFj8pRAnxCHvQzt9OAh=kS+JTNqdP9rd2TDieRODC-HfKR92Dw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [PATCH] SQL function to report log message (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: [PATCH] SQL function to report log message
|
| Список | pgsql-hackers |
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.
> I am strong in my opinion about PLpgSQL RAISE statement behave, but on
> second hand, proposed function should not be 100% same as RAISE stmt. More
> we can simply add a parameter like "ignore_nulls"
I would be willing to bet you a drink that 99.9% of people will want
the behavior Jim is advocating, so I don't think this should be
configurable.
99.9% of people can think so it is good idea to the moment, when the important information will be lost without any hint, why it was lost.
Default behave can be like Jim proposed.
В списке pgsql-hackers по дате отправления: