andy <[EMAIL PROTECTED]> 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

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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?


Reply via email to