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
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
