Re: tsearch2 in PostgreSQL 8.3?

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.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

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