From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michal Hlavac <hlavki(at)medium13(dot)sk> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: pg_dump and tsearch2 |
Date: | 2004-06-07 14:05:12 |
Message-ID: | 2755.1086617112@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Michal Hlavac <hlavki(at)medium13(dot)sk> writes:
> sorry for my strictness. My problem is with type tsvector.
> It is because declaration of tsvector is after declaration of table with
> tsvector column...
Right. This typically happens when you added a tsvector column to a
table that existed before the tsvector type was created. 7.4 and before
pg_dump tend to dump the objects in creation order and so have a
problem. (CVS tip pg_dump is smarter, but I don't know if you can/want
to use it.)
What would probably work is to load the tsearch stuff into the new
database and then restore your dump. You'll get errors when the script
tries to load the old tsearch objects, but you can ignore them.
If you're using pg_restore, another way is to make use of the feature
pg_restore has for manual control of the restore order.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Együd Csaba | 2004-06-07 14:31:51 | Re: pg_dump, bytea, dump order questions |
Previous Message | Richard Huxton | 2004-06-07 13:56:56 | Re: Backup and Restore of PostgreSQL |