Re: tsearch_core for inclusion

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

In response to

Browse pgsql-hackers by date

  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