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