Re: full text search in 8.3

Поиск
Список
Период
Сортировка
От Florian G. Pflug
Тема Re: full text search in 8.3
Дата
Msg-id 470E2BBB.5000703@phlo.org
обсуждение исходный текст
Ответ на Re: full text search in 8.3  (andy <andy@squeakycode.net>)
Ответы Re: full text search in 8.3  (andy <andy@squeakycode.net>)
Re: full text search in 8.3  ("Nikolay Samokhvalov" <samokhvalov@gmail.com>)
Re: full text search in 8.3  (andy <andy@squeakycode.net>)
Список pgsql-hackers
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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Timezone database changes
Следующее
От: Gregory Stark
Дата:
Сообщение: Re: First steps with 8.3 and autovacuum launcher