Re: [PATCH] SQL function to report log message - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [PATCH] SQL function to report log message
Date
Msg-id CAFj8pRDC4EGcJ0yXX2vS1uBOCsfGENVTUZCva8Pgb=mMUj0xRA@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] SQL function to report log message  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers




2015-10-23 0:07 GMT+02:00 Jim Nasby <Jim.Nasby@bluetreble.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

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Change behavior of (m)xid_age
Next
From: Alvaro Herrera
Date:
Subject: Re: Change behavior of (m)xid_age