Re: [PATCH] SQL function to report log message

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [PATCH] SQL function to report log message
Дата
Msg-id CA+TgmoZ8hnz01u+LeVTDbEKE0yh0_2CA3-Qs9fSvdapNT_C_kw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] SQL function to report log message  (dinesh kumar <dineshkumar02@gmail.com>)
Ответы Re: [PATCH] SQL function to report log message  (dinesh kumar <dineshkumar02@gmail.com>)
Список pgsql-hackers
On Wed, Jul 22, 2015 at 9:56 PM, dinesh kumar <dineshkumar02@gmail.com> wrote:
>> 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.
>>
>
> 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.

But, why?

I just took a look at the latest patch and I can't see why it's any
better than just using PL/pgsql's RAISE statement.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: Autonomous Transaction is back
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Counting lines correctly in psql help displays