| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: CREATE FUNCTION .. SET vs. pg_dump |
| Date: | 2013-09-03 16:15:40 |
| Message-ID: | CA+TgmoaYPkVDRLd_yAhiZgAuQqr3uW8YRc7_v5c7CD9Eqp=VgA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Sep 1, 2013 at 10:36 AM, Stefan Kaltenbrunner
<stefan(at)kaltenbrunner(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomonari Katsumata | 2013-09-03 16:16:49 | The PostgreSQL License requires "LICENSE" file? |
| Previous Message | Andres Freund | 2013-09-03 16:05:29 | Re: logical changeset generation v5 |