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 <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
