> 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 

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.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to