Re: tsearch2 in PostgreSQL 8.3? - Mailing list pgsql-hackers
From | Robert Treat |
---|---|
Subject | Re: tsearch2 in PostgreSQL 8.3? |
Date | |
Msg-id | 200708171035.52504.xzilla@users.sourceforge.net Whole thread Raw |
In response to | Re: tsearch2 in PostgreSQL 8.3? (Bruce Momjian <bruce@momjian.us>) |
Responses |
Re: tsearch2 in PostgreSQL 8.3?
Re: tsearch2 in PostgreSQL 8.3? |
List | pgsql-hackers |
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
pgsql-hackers by date: