Re: [PATCH] SQL function to report log message

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [PATCH] SQL function to report log message
Дата
Msg-id CAFj8pRBV8zO3XF=hxnHHNB80cVHJXU63Z__19p2JaqeLWws-5w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] SQL function to report log message  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: [PATCH] SQL function to report log message
Список pgsql-hackers


2015-10-18 21:13 GMT+02:00 Jim Nasby <Jim.Nasby@bluetreble.com>:
On 10/17/15 11:49 AM, Pavel Stehule wrote:
2015-10-17 18:42 GMT+02:00 Jim Nasby <Jim.Nasby@bluetreble.com
<mailto:Jim.Nasby@bluetreble.com>>:

    On 10/15/15 11:51 PM, Pavel Stehule wrote:

        I don't think so ignoring NULL in RAISE statement is good idea
        (it is
        not safe). We can replace NULL by some string (like "NULL") by
        default.
        I am thinking about other possibilities.


    What I was trying to say is that if the argument to a USING option
    is NULL then RAISE should skip over it, as if it hadn't been applied
    at all. Similar to how the code currently tests for \0.


I understand, but I don't prefer this behave. The NULL is strange value
and should be signalized.

So instead of raising the message we wanted, we throw a completely different exception? How does that make sense?

It is partially wrong because we handle all fields same. It has sense for "message" fields, and has not sense for other fields. In this case the text "NULL" will be better.
 

More to the point, if RAISE operated this way then it would be trivial to create a fully functional plpgsql wrapper around it.

I have a different opinion - better to have propossed function in core. What I know, the NULL is not use in Postgres as "ignore value", and I am thinking, it is good idea.

Regards

Pavel
 

--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

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

Предыдущее
От: Kouhei Kaigai
Дата:
Сообщение: Re: Foreign join pushdown vs EvalPlanQual
Следующее
От: Etsuro Fujita
Дата:
Сообщение: Re: Foreign join pushdown vs EvalPlanQual