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

From dinesh kumar
Subject Re: [PATCH] SQL function to report log message
Date
Msg-id CALnrH7pA95p8mrGOfvn97WXsKpQmMaQZqN1bKZN_rNxmxp4ESw@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] SQL function to report log message  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] SQL function to report log message  (Michael Paquier <michael.paquier@gmail.com>)
Re: [PATCH] SQL function to report log message  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hi All,

On Mon, Jul 13, 2015 at 2:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
> On 7/13/15 3:39 PM, dinesh kumar wrote:
>> Ah. It's' my bad interpretation. Let me work on it, and will send a new
>> patch as a wrapper sql function for ereport.

> You might want to present a plan for that; it's not as trivial as it
> sounds due to how ereport works. In particular, I'd want to see (at
> minimum) the same functionality that plpgsql's RAISE command now
> provides (errdetail, errhint, etc).


Jim,

For now, I  worked on (ERROR Level, ERROR Message, HIDE ERROR Stmt). In our to do item description, I found this wrapper needs to return "Anyelement".  But, I believe, return "VOID" is enough for this function. Let me know if I erred here.

In design phase,

1. I took a CustomDataType with the elevel code, elevel text

2. Populated this CDT with all existing pre-processors, except {FATAL, PANIC}. Since, we don't expose these to client.

3. By matching the user elevel text, processing the report log function.

Find the attached patch with implementation.

 
The real question is why the existing functionality in plpgsql isn't
sufficient.  Somebody who wants a "log from SQL" function can easily
write a simple plpgsql function that does exactly what they want,
with no more or fewer bells-n-whistles than they need.  If we try
to create a SQL function that does all that, it's likely to be a mess
to use, even with named arguments.

I'm not necessarily against the basic idea, but I think inventing
something that actually offers an increment in usability compared
to the existing alternative is going to be harder than it sounds.


Tom,

I agree with your inputs. We can build  pl/pgsql function as alternative for this.

My initial proposal, and implementation was, logging messages to log file irrespectively of our log settings. I was not sure we can do this with some pl/perlu. And then, I started working on our to do item,
ereport, wrapper callable from SQL, and found it can be useful to have a direct function call with required log level.

Thanks.

Regards,
Dinesh
                        regards, tom lane

Attachment

pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Asynchronous execution on FDW
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: RFC: replace pg_stat_activity.waiting with something more descriptive