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