Re: [HACKERS] CREATE FUNCTION .. SET vs. pg_dump

2013-09-03 Thread Tom Lane
Robert Haas writes: > On Sun, Sep 1, 2013 at 10:36 AM, Stefan Kaltenbrunner > wrote: >> 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 h

Re: [HACKERS] CREATE FUNCTION .. SET vs. pg_dump

2013-09-03 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote: > So I think a more reasonable fix is just to skip the ProcessGUCArray > call altogether when check_function_bodies = false, and to document > that validators mustn't assume anything about the GUC environment > when check_function_bodies = false. > > If no ob

Re: [HACKERS] CREATE FUNCTION .. SET vs. pg_dump

2013-09-03 Thread Stefan Kaltenbrunner
On 09/03/2013 06:15 PM, Robert Haas wrote: > On Sun, Sep 1, 2013 at 10:36 AM, Stefan Kaltenbrunner > 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 t

Re: [HACKERS] CREATE FUNCTION .. SET vs. pg_dump

2013-09-03 Thread Robert Haas
On Sun, Sep 1, 2013 at 10:36 AM, Stefan Kaltenbrunner 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 sh

Re: [HACKERS] CREATE FUNCTION .. SET vs. pg_dump

2013-09-01 Thread Stefan Kaltenbrunner
On 09/01/2013 12:53 AM, Stephen Frost wrote: > * Stefan Kaltenbrunner (ste...@kaltenbrunner.cc) wrote: >> On 08/18/2013 05:40 PM, Tom Lane wrote: >>> Stefan Kaltenbrunner writes: While working on upgrading the database of the search system on postgresql.org to 9.2 I noticed that the dump

Re: [HACKERS] CREATE FUNCTION .. SET vs. pg_dump

2013-08-31 Thread Stephen Frost
* Stefan Kaltenbrunner (ste...@kaltenbrunner.cc) wrote: > On 08/18/2013 05:40 PM, Tom Lane wrote: > > Stefan Kaltenbrunner writes: > >> While working on upgrading the database of the search system on > >> postgresql.org to 9.2 I noticed that the dumps that pg_dump generates on > >> that system are

Re: [HACKERS] CREATE FUNCTION .. SET vs. pg_dump

2013-08-31 Thread Stefan Kaltenbrunner
On 08/18/2013 05:40 PM, Tom Lane wrote: > Stefan Kaltenbrunner writes: >> While working on upgrading the database of the search system on >> postgresql.org to 9.2 I noticed that the dumps that pg_dump generates on >> that system are actually invalid and cannot be reloaded without being >> hacked o

Re: [HACKERS] CREATE FUNCTION .. SET vs. pg_dump

2013-08-18 Thread Stefan Kaltenbrunner
On 08/18/2013 05:40 PM, Tom Lane wrote: > Stefan Kaltenbrunner writes: >> While working on upgrading the database of the search system on >> postgresql.org to 9.2 I noticed that the dumps that pg_dump generates on >> that system are actually invalid and cannot be reloaded without being >> hacked o

Re: [HACKERS] CREATE FUNCTION .. SET vs. pg_dump

2013-08-18 Thread Tom Lane
Stefan Kaltenbrunner writes: > While working on upgrading the database of the search system on > postgresql.org to 9.2 I noticed that the dumps that pg_dump generates on > that system are actually invalid and cannot be reloaded without being > hacked on manually... > CREATE TEXT SEARCH CONFIGURAT

[HACKERS] CREATE FUNCTION .. SET vs. pg_dump

2013-08-18 Thread Stefan Kaltenbrunner
Hi all! While working on upgrading the database of the search system on postgresql.org to 9.2 I noticed that the dumps that pg_dump generates on that system are actually invalid and cannot be reloaded without being hacked on manually... Simple way to reproduce is using the following: CREATE T