Re: tsearch_core for inclusion

On Mon, 26 Mar 2007, Tom Lane wrote:

> Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> writes:
>> On Fri, 23 Mar 2007, Florian G. Pflug wrote:
>>> Isn't the real problem that only _one_ configuration per locale should
>>> be marked as DEFAULT at any time, no matter what schema it is in?
>
>> I'm not sure I understand you correct (a bit complex :), but it's allowed
>> to have only _one_ DEFAULT configuration per schema/per locale. So,
>> visibility is defined by search_path for given locale.
>
> Not sure that that's a good idea at all. We used to have
> search-path-dependent rules for deciding which opclass was default,
> and found that that was not good. Also, I do not understand how
> the queries and the indexes are tied together --- but doesn't an
> index need to be built using the same rules that are later expected
> by the queries? If that varies on search_path it'll be too fragile.

fts is a very rich application and the rules for creating index and
queries could be different. One index could be used for searching
with/without taking into account stop-words, for example.
But, in general, index and queries should be processed by the same
parsers and dictionaries. It can be less fragile, if we store somehow
fts information (fts configuration name) to display it, say, in \di command.

I repeat, I see potential problem (confusion) only for "simple" fts index,
which creates on TEXT/VARCHAR data, using CREATE INDEX command, since it's
impossible explicitly specify which fts configuration to use.

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83