From: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
---|---|
To: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> |
Cc: | Teodor Sigaev <teodor(at)sigaev(dot)ru>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: tsearch_core for inclusion |
Date: | 2007-03-16 22:09:03 |
Message-ID: | 45FB157F.3010501@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Treat wrote:
> On Friday 16 March 2007 10:45, Teodor Sigaev wrote:
>>> I don't see how the proposal is going to solve that type of problem, but
>>> maybe I am overlooking something?
>> The same way as other system tables objects, they don't dump, they don't
>> restore. In 8.3, seems, API to index AM will be changed - will anybody
>> except pghackers see that? New opclass layout, new opfamily table - users
>> don't that changes at all.
>
> If I have configured my tsearch install for spanish (spanish
> dictionary/stemmers/synonyms/etc...) aren't I going to lose all that on the
> next database upgrade?
I believe what teodor meant is that the *tables* won't be dumped as such
by pg_dump (the same as all other tables in pg_catalog). But pg_dump would
of course need to dump the information stored in the tables - it would
put some "CREATE FULLTEXT ... " statements into your dump. Its really
the same as for any other database object like a function, a type, ...
greetings, Florian Pflug
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2007-03-16 22:10:16 | Re: Buildfarm feature request: some way to track/classify failures |
Previous Message | Jeremy Drake | 2007-03-16 21:48:56 | Re: Buildfarm feature request: some way to track/classify failures |