Re: [PATCH] SQL function to report log message

2015-10-16 2:47 GMT+02:00 Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>:

> On 9/10/15 10:56 AM, Andres Freund wrote:
>
>> >The only complaint I've seen in this thread that seems like a valid
>>> >deficiency is that RAISE can't deal with treating the error severity
>>> level
>>> >as a variable. But surely we should address that as a new RAISE
>>> feature,
>>> >not by inventing a SQL wrapper that will need to reproduce every
>>> existing
>>> >RAISE feature before it can think about solving anything new.
>>>
>> That seems like something independently useful.
>>
> fa
> If we're up for that the other thing I'd add is having raise ignore
> anything supplied by USING that's NULL, instead of treating it as an error.
> That would make it very easy to create a wrapper function that exposes the
> full capabilities of RAISE.
>

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.

1. some RAISE statement flag - but there was strong disagreement when I did
it last time
2. some plpgsql GUC variables like plpgsq.raise_ignore_null
3. accept a function from this patch

Now, I am thinking so @3 is good option. It can be really useful as last
rescue for other PL without possibility to raise rich PostgreSQL exception
- currently PLPythonu, partially PLPerl (where are more issues), probably
in others.

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
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>