Tom Lane wrote:
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
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
I have the sql script to create the tables (I was going to pg_dump
--schema-only and edit, but there is a lot of stuff in there). I just
ran it to create empty tables, then did the pg_dump --data-only, and
scripted it in.
Worked fine.
Changed the trigger from calling tsearch2 to tsvector_update_trigger.
Then in my php I changed:
to_tsquery('default', '$fulltext')
to
to_tsquery('$fulltext')
and renamed rank to ts_rank, and my site (well, the test site) is happy
on 8.3.
-Andy
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
