From: | dinesh kumar <dineshkumar02(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(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-07-23 01:56:16 |
Message-ID: | CALnrH7pA95p8mrGOfvn97WXsKpQmMaQZqN1bKZN_rNxmxp4ESw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi All,
On Mon, Jul 13, 2015 at 2:12 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)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
manojadinesh.blogspot.com
regards, tom lane
>
Attachment | Content-Type | Size |
---|---|---|
02v_PgReportLog.diff | text/plain | 5.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2015-07-23 02:57:49 | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |
Previous Message | Kyotaro HORIGUCHI | 2015-07-23 01:25:24 | Re: Asynchronous execution on FDW |