| 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: | Whole Thread | Raw Message | 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 |