Re: CREATE FUNCTION .. SET vs. pg_dump - Mailing list pgsql-hackers

From Tom Lane
Subject Re: CREATE FUNCTION .. SET vs. pg_dump
Date
Msg-id 21162.1376840447@sss.pgh.pa.us
Whole thread Raw
In response to CREATE FUNCTION .. SET vs. pg_dump  (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>)
Responses Re: CREATE FUNCTION .. SET vs. pg_dump  (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>)
Re: CREATE FUNCTION .. SET vs. pg_dump  (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>)
List pgsql-hackers
Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> 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 CONFIGURATION pg (
>     PARSER = pg_catalog."default" );

> CREATE FUNCTION test() RETURNS INTEGER
> LANGUAGE sql SET default_text_search_config TO 'public.pg' AS $$
> SELECT 1;
> $$;

> once you dump that you will end up with an invalid dump because the
> function will be dumped before the actual text search configuration is
> (re)created.

I don't think it will work to try to fix this by reordering the dump;
it's too easy to imagine scenarios where that would lead to circular
ordering constraints.  What seems like a more workable answer is for
CREATE FUNCTION to not attempt to validate SET clauses when
check_function_bodies is off, or at least not throw a hard error when
the validation fails.  (I see for instance that if you try   ALTER ROLE joe SET default_text_search_config TO
nonesuch;
you just get a notice and not an error.)

However, I don't recall if there are any places where we assume the
SET info was pre-validated by CREATE/ALTER FUNCTION.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: pgbench / compatibility with old(er) releases
Next
From: Tom Lane
Date:
Subject: Re: pgbench / compatibility with old(er) releases