On 9/9/15 5:27 PM, Robert Haas wrote:
Sure, it’s a clear fact that, we can implement this function with RAISE
>statements.
Given that, I suggest we just forget the whole thing.
Except that you can't use a variable to control the log level in a
plpgsql RAISE, so then you end up with a CASE statement. That perhaps
wouldn't be so bad, until you also want to optionally report detail,
hint, and/or errcode. So trying to create a generic wrapper around RAISE
is decidedly non-trivial. Another option is removing those restrictions
from RAISE, but it seems a bit silly to take the hit of firing up a
plpgsql function for this.
So I think there is value in a SQL equivalent to RAISE. I'm not thrilled
by piling another hack onto the horribly inadequate errlevel
infrastructure, but at least Dinesh's "MESSAGE" idea is essentially just
side-stepping that hole instead of digging it deeper.
--
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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
