Robert Treat wrote:
> > The only remaining problem I see is that the rest of the documentation
> > relies heavily on default_text_search_config when in fact the most
> > common usage with tables and indexes can't use it. tsquery can use the
> > default easily, but I am betting that tsvector usually cannot.
>
> What exactly does default_text_search_config buy us? I think it is supposed
> to simplify things, but it sounds like it adds a bunch of corner cases,
> special siutations, if's and but's (and candies and nuts), that I fear will
> lead to more confusion for end users, and make development more difficult in
> the future as we forced to try and live with backwards compatability.
Agreed. That was my conclusion long ago but few agreed so I gave up.
In fairness the goal was for default_text_search_config to make text
search easier for clusters that use a single configuration. If you are
using triggers on a separate tsvector column, only the trigger author
needs to deal with the configuration name (not queries), but expression
indexes require the configuration name to always be used for the
tsvector queries, while the tsquery can use the
default_text_search_config value. Anyway, again, it is all
special-casing this and that, as you said. And, if you are specifying
the configuration name for the tsvector but not the tsquery you are more
likely to have a configuration mismatch. (Of course you might want
different configurations for tsvector and tsquery, but that is for
experts.)
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
