Re: tsearch2 in PostgreSQL 8.3?

On Thursday 16 August 2007 15:58, Bruce Momjian wrote:
> Josh Berkus wrote:
> > All,
> >
> > First off, I'll assert that backup/restore is a serious issue and while
> > the folks who want Tsearch in core now are dismissing it, we'll be
> > fielding the complaints later. Any solution which involves setting a GUC
> > at restore time *which could vary per table or even column* isn't
> > acceptable. We used to do the \SET thing for table ownership with
> > backup/restore, and you *know* how many restore failures that caused.
>
> Agreed. Let me summarize where we are now. I talked to Tom on the
> phone yesterday so we have come up with the following plan:
>
> o default_text_search_config stays, not super-user-only, not set
> in pg_dump output
> o tsearch functions that don't have a configuration name will be
> marked so they can't be specified in expression indexes
> o auto-casts and "::" to tsearch data types will also not work in
> expression indexes (we already do this for timestamp without
> timezone)
> o GIN on an text column will not promote to tsvector
> o No rewrite magic for function calls without configuration names in
> WHERE clauses to use indexes that do specify configurations (risky)
>
> The current documentation explains all this:
>
> http://momjian.us/expire/textsearch/HTML/textsearch-tables.html
>
> So, we have disabled the ability to create expression indexes that are
> affected by default_text_search_config, and we have documented other
> possible problems. tsvector_update_trigger() has to be modified to
> take a configuration name (and frankly I am not excited about the
> filter_name capability either, but that is a separate issue).
>
> 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.

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL