Re: full text search in 8.3

Tom Lane wrote:
> 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


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