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
havea configuration name will be marked so they can't be specified in expression indexes o auto-casts and "::" to
tsearchdata 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.
-- 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. +
