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

From Tom Lane
Subject Re: [PATCH] SQL function to report log message
Date
Msg-id 4196.1441856708@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] SQL function to report log message  (David Fetter <david@fetter.org>)
Responses Re: [PATCH] SQL function to report log message  (dinesh kumar <dineshkumar02@gmail.com>)
Re: [PATCH] SQL function to report log message  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
David Fetter <david@fetter.org> writes:
> On Thu, Sep 10, 2015 at 01:32:10AM +0200, Andres Freund wrote:
>> I'm not convinced. Sure, it's easy, but I by now have written the
>> respective function dozens of times. Why should we force that on
>> everyone?

> +20 or so here, that being the number of times I recall offhand having
> written the function.

Were all twenty of them exactly alike?  Were they identical to Andres'
several dozen attempts?

The problem I've got with this proposal is that by the time you get to
a function that could satisfy every possible use-case, you do not have
something that is easier to use than "write your own function that
addresses just your use-case".

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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: function parse_ident
Next
From: Amit Kapila
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file