From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | andy <andy(at)squeakycode(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: full text search in 8.3 |
Date: | 2007-10-10 21:50:27 |
Message-ID: | 24958.1192053027@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
andy <andy(at)squeakycode(dot)net> writes:
> Tom Lane wrote:
>> Did the data transfer over? The declarations of the former contrib
>> functions would of course fail, but type tsvector is still there.
>> I would like to think that ignoring pg_restore's whining would get
>> you most of the way there.
> So I tried again: The long answer is no, the table with the tsvector
> did not get created, and thus, not copied:
> pg_restore: [archiver (db)] could not execute query: ERROR: type
> "tsvector" is only a shell
> LINE 11: vectors tsvector
> ^
> Command was: CREATE TABLE times (
Hmph, that's annoying. I suppose the problem is that the script has
just set the search path to "public, pg_catalog", and so the failed
shell tsvector type in public is found in preference to the one in
pg_catalog.
What you could probably do as a workaround for testing is to create a
dummy type entry to block the creation of the shell type, say
create domain public.tsvector as pg_catalog.tsvector;
and then run pg_restore. This seems pretty ugly though ... anyone
have a better idea?
(Knew we should have insisted on seeing a migration plan sooner.
Oh well.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | andy | 2007-10-10 21:57:39 | Re: full text search in 8.3 |
Previous Message | andy | 2007-10-10 21:31:27 | Re: full text search in 8.3 |