From: | George Essig <george_essig(at)yahoo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Problem resolved (tsearch2 inhibiting migration) |
Date: | 2005-02-04 15:11:09 |
Message-ID: | 20050204151109.66001.qmail@web53704.mail.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> We could decree that a contrib module's script should create a schema
> and shove everything it makes into that schema. Then "DROP SCHEMA CASCADE"
> is all you need to get rid of it. However, you'd probably end up having
> to add this schema to your search path to use the module conveniently.
>
> regards, tom lane
I currently load tsearch2 into a separate schema. It's a convenient way to separate tsearch2 from
the rest of the database for backup procedures and listing database objects. To make this work as
transparently as possible, I update the search_path to include the new schema to avoid explicit
references. The only problem is that the search_path is stored in the catalog and not outputted
in pg_dump files. You have to remember to set the search_path after restoring the database.
George Essig
From | Date | Subject | |
---|---|---|---|
Next Message | Bricklen Anderson | 2005-02-04 15:14:14 | Re: Invalid headers and xlog flush failures |
Previous Message | Mike Rylander | 2005-02-04 15:07:53 | Re: error-tolerant COPY FROM |