> Hmm. The meaning of funcs.inline depends on the search_path, not just during > dump restoration but all the time. So anything uses it under a different > search_path setting than the normal one will have this kind of problem; not > just
> dump/restore. > I don't have a very good idea what to do about that. > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company I wasn't suggesting it was a restore only issue, but it's most felt when your data doesn't come back. It affects any extension that relies on another extension. Take for example, I have tiger geocoder which relies on fuzzystrmatch. I have no idea where someone installs fuzzystrmatch so I can't schema qualify those calls. I use that dependent function to use to build an index on tables. The indexes don't come back. What I was trying to suggest (side topic, forget about inline issue), Is the pg_dump should have a switch to allow users to tack on extra schemas So that the dump restore set search_path thing looks like: Set search_path=my_data_schema, pg_catalog, whatever_otehr_schemas_I_have_for_db People can choose to use that switch or not. So that way if people do have database search_paths, they normally run with, their data will come back. Am I missing something here in this suggestion? It's one of the most common complaints I hear about PostgreSQL in general and the crazy things people do to get around the issue like doing plain text dumps and parsing the dump. Thanks, Regina -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
