| From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | David Fetter <david(at)fetter(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, dinesh kumar <dineshkumar02(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PATCH] SQL function to report log message |
| Date: | 2015-10-16 00:47:31 |
| Message-ID: | 56204923.4080508@BlueTreble.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
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.
--
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Nasby | 2015-10-16 01:13:27 | Re: pg_dump LOCK TABLE ONLY question |
| Previous Message | Jim Nasby | 2015-10-16 00:28:09 | Re: Improve the concurency of vacuum full table and select statement on the same relation |