On Mon, 26 Mar 2007, Tom Lane wrote:
Oleg Bartunov <oleg@sai.msu.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@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
