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  (Robert Haas <robertmhaas@gmail.com>)
Список 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. 


 

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: ROWS FROM(): A Foolish (In)Consistency?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Multi-column distinctness.