From: | Richard Huxton <dev(at)archonet(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Full-text search default vs specified configuration |
Date: | 2008-02-22 17:53:29 |
Message-ID: | 47BF0C19.3070605@archonet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Richard Huxton <dev(at)archonet(dot)com> writes:
>> Would there be any support for two changes in 8.4 though?
>
>> 1. Tag tsvector/tsquery's with the (oid of) their configuration?
>
>> 2. Either warn or require CASCADE on changes to a
>> configuration/dictionary that could impact existing indexes etc.
>
> IIRC, the current behavior is intentional --- Oleg and Teodor argued
> that tsvector values are relatively independent of small changes in
> configuration and we should *not* force people to, say, reindex their
> tables every time they add or subtract a stopword. If we had some
> measure of whether a TS configuration change was "critical" or not,
> it might make sense to restrict critical changes; but I fear that
> would be kind of hard to determine.
Well, clearly in my example it didn't impact operation at all, but it's
an accident waiting to happen (and more importantly, a hard one to track
down). It's like running SQL-ASCII encoding, everything just ticks along
only to cause problems a month later.
What about the warning: "This may affect existing indexes - please
check". Would that cause anyone problems?
What worries me is that it might take 10 messages on general/sql list to
figure out the problem. This was reported as "words with many hits
causes problems".
Maybe it's just a matter of getting the message out: "always specify the
config or never specify the config".
--
Richard Huxton
Archonet Ltd
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-02-22 17:54:00 | Re: 8.3 / 8.2.6 restore comparison |
Previous Message | Tom Lane | 2008-02-22 17:50:10 | Re: Including PL/PgSQL by default |