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 
  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:

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.

  Bruce Momjian  <[EMAIL PROTECTED]>

  + If your life is a hard drive, Christ can be your backup. +

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

Reply via email to