Re: full text search in 8.3
От | Tom Lane |
---|---|
Тема | Re: full text search in 8.3 |
Дата | |
Msg-id | 24958.1192053027@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: full text search in 8.3 (andy <andy@squeakycode.net>) |
Ответы |
Re: full text search in 8.3
|
Список | pgsql-hackers |
andy <andy@squeakycode.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
В списке pgsql-hackers по дате отправления: