Re: full text search in 8.3

From: andy <andy(at)squeakycode(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: full text search in 8.3
Date: 2007-10-11 14:06:04
Message-ID: 470E2DCC.8060506@squeakycode.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Florian G. Pflug wrote:
> andy wrote:
>> Is there any chance there is an easier way to backup/restore? On one
>> hand, its not too bad, and it'll only be once (correct?). Now that
>> fts is in core future backup/restores will work, right? I think it's
>> analogous to telling someone they are updating from tsearch2 to
>> tsearch3, and it might be a little more painful than just a
>> backup/restore.
>>
>> On the other hand I think a backup/restore will pollute the new db
>> with a bunch of functions and types that wont ever be used, so it's so
>> much cleaner to build it by hand.
>>
>> Are there other fts users that might have opinions on that?
>
> I'm not really a tsearch user (just played with it a bit once). But I
> wondered if you are aware that you can prevent certain objects from
> being restored
> quite easiy if you use pg_dump and pg_restore together with "custom
> format" (-Fc). There is some option to pg_restore that reads the dump,
> and ouputs a table of contents. You can then remove some entries from
> that list, and pass the modified list to pg_restore which will skip
> entries that do not show up on your modified list.
>
> Maybe we could document some regexp, awk script, or similar that strips
> the tsearch stuff from such a table of contents?
>
> regards, Florian Pflug
>

Ahh, I did not know that... I'll try that out and see if I can come up
with something. Thanks!

-Andy

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2007-10-11 14:13:24 Re: Timezone database changes
Previous Message Gregory Stark 2007-10-11 13:57:22 Re: First steps with 8.3 and autovacuum launcher