Re: Subtle pg_dump problem...

OK, I'll try to explain it better.

1. Tsearch2 requires access to several tables.

2. You can edit the tsearch2.sql script and change the "set schema = 
..." to contrib.

3. You load all the tsearch2 objects into contrib.

4. You create a table in the public schema with a column of type 
contrib.vector, and a trigger of contrib.tsearch2.

5. You pg_dump that table, you get:

SET search_path = public, pg_catalog;

COPY ...

(Because the table is in the public schema)

6. However, it is now not possible to restore the sql script as it was 
dumped, as you get this error:

ERROR:  relation "pg_ts_cfg" does not exist

7. You get this error because the tsearch2 code depends on the current 
search path, and since contrib is not in the search path, the restore fails.

8. This problem occurs because tsearch2 is dependent on the current 
user's search_path.  Instead, it should be independent of the current 
user's search path, and instead try to find its configuration tables in 
the same schema in which the vector type or the tsearch2 trigger 
function resides.

This assumes that the user has installed all the tsearch2 objects into 
the same schema, which I think is reasonable.

This problem will occur for anyone who has multiple schemas and tries to 
create vector columns in tables that refer to the vector type in another 
schema.

Does that make sense?

Chris