Re: [PATCH] SQL function to report log message

2015-10-23 0:07 GMT+02:00 Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>:

> On 10/22/15 4:59 PM, Pavel Stehule wrote:
>
>> It prevents everyone from reinventing the 'create a function wrapper
>> around RAISE' wheel that several people on this list alone have
>> admitted to. I think there's plenty of value in that.
>>
>>
>> I have different opinion, I am sorry. The RAISE statement is differently
>> designed with different possibility - the function is limited by using
>> variadic function, and should not to have same behave as RAISE. And I
>> don't like a idea to push RAISE to behave of variadic function.
>>
>
> I thought the only issue here was that RAISE currently pukes on a NULL
> input, and I thought you'd changed your mind and agreed that it makes sense
> for RAISE to just silently ignore anything that's NULL (except maybe for
> message). Am I wrong on one or both counts?
>
>
Maybe I don't use some words exactly - but I newer though so RAISE can
ignore NULLs. Current behave of RAISE is probably too strict - the
exception is too hard, but the NULL value should be displayed. In the
function, the NULL can be ignored, because we cannot to do better (we have
not same possibility like Python has) - and I am able to accept it in this
case.

> IIRC 3 or 4 people on this list liked the idea of a function roughly
> equivalent to RAISE, to avoid the make-work of writing that function.
> That's why I disagree with your statement that there's no point to this
> function even if it acts the same as RAISE.

I didn't see any strong agreement to change RAISE statement here. The talk
here was about displayed informations - the function should to display all
possible fields - but it is based more on ErrorData structure, than on
RAISE statement.

>
> --
> 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
>