On 08/18/2013 05:40 PM, Tom Lane wrote: > Stefan Kaltenbrunner <ste...@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.
any further insights into that issue? - seems a bit silly to have an open bug that actually prevents us from taking (restorable) backups of the search system on our own website... Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
