Re: CREATE FUNCTION .. SET vs. pg_dump

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: CREATE FUNCTION .. SET vs. pg_dump
Дата
Msg-id CA+TgmoaYPkVDRLd_yAhiZgAuQqr3uW8YRc7_v5c7CD9Eqp=VgA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: CREATE FUNCTION .. SET vs. pg_dump  (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>)
Ответы Re: CREATE FUNCTION .. SET vs. pg_dump  (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>)
Re: CREATE FUNCTION .. SET vs. pg_dump  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Sun, Sep 1, 2013 at 10:36 AM, Stefan Kaltenbrunner
<stefan@kaltenbrunner.cc> wrote:
>> It would seem that a simple solution would be to add an elevel argument
>> to ProcessGUCArray and then call it with NOTICE in the case that
>> check_function_bodies is true.  None of the contrib modules call
>> ProcessGUCArray, but should we worry that some external module does?
>
> attached is a rough patch that does exactly that, if we are worried
> about an api change we could simple do a ProcessGUCArrayNotice() in the
> backbranches if that approach is actually sane.

This patch has some definite coding-style issues, but those should be
easy to fix.  The bigger thing I worry about is whether distributing
the decision as to what elevel ought to be used here all over the code
base is indeed sane.  Perhaps that ship has already sailed, though.

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



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: logical changeset generation v5
Следующее
От: Tomonari Katsumata
Дата:
Сообщение: The PostgreSQL License requires "LICENSE" file?