Re: [PATCH] SQL function to report log message

Поиск
Список
Период
Сортировка
От dinesh kumar
Тема Re: [PATCH] SQL function to report log message
Дата
Msg-id CALnrH7pA95p8mrGOfvn97WXsKpQmMaQZqN1bKZN_rNxmxp4ESw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] SQL function to report log message  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы 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>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: Asynchronous execution on FDW
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: RFC: replace pg_stat_activity.waiting with something more descriptive