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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to