Re: default_text_search_config and expression indexes - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: default_text_search_config and expression indexes
Date
Msg-id 200707312302.l6VN2ER09809@momjian.us
Whole thread Raw
In response to Re: default_text_search_config and expression indexes  (Oleg Bartunov <oleg@sai.msu.su>)
Responses Re: default_text_search_config and expression indexes
Re: default_text_search_config and expression indexes
List pgsql-hackers
Oleg Bartunov wrote:
> On Tue, 31 Jul 2007, Bruce Momjian wrote:
> 
> >>> And if we have to require the configuration name in CREATE INDEX, it has
> >>> to be used in WHERE, so we might as well just remove the default
> >>> capability and always require the configuration name.
> >>
> >> this is very rare use case for text searching
> >> 1. expression index without configuration name
> >> 2. default_text_search_config can be changed by somebody
> >
> > If you are going to be using the configuration name with the create
> > expression index, you have to use it in the WHERE clause (or the index
> > doesn't work), and I assume that is 90% of the text search uses.  I
> > don't see it as rare at all.
> 
> What is a basis of your assumption ? In my opinion, it's very limited
> use of text search, because it doesn't supports ranking. For 4-5 years
> of tsearch2 usage I never used it and I never seem in mailing lists.
> This is very user-oriented feature and we could probably ask 
> -general people for their opinion.

I doubt 'general' is going to understand the details of merging this
into the backend.  I assume we have enough people on hackers to decide
this.

Are you saying the majority of users have a separate column with a
trigger?  Does the trigger specify the configuation?  I don't see that
as a parameter argument to tsvector_update_trigger().  If you reload a
pg_dump, what does it use for the configuration?

Why is a separate column better than the index?  Just ranking?

The reason the expression index is nice is this feature has to be easy
to use for people who are new to full text and even PostgreSQL.  Right
now /contrib is fine for experts to use, but we want a larger user base
for this feature.

> >> If somebody really need it, then he should be adviced to use configuration
> >> name, else we don't guarantee that somebody could change
> >> default_text_search_config  variable and this could lead to
> >> incorrect dump/restore.
> >>
> >> I don't think we should remove default_text_search_config because of
> >> this rare case.
> >
> > I still feel the default_text_search_config has to be removed.  We have
> > tried all sorts of ways to make it work but having it not be 100%
> > reliable for pg_dump/restore means it might as well be in /contrib and
> > unsupported.  If we have it in core, it has to work 100%.  We can't have
> > tons of examples that don't specify the configuration name and then
> > expect every create expression index and WHERE clause to use it.
> > default_text_search_config _can_ work, but it seems so easy to break and
> > so easy to get wrong that I think it must be removed.
> 
> I'd better say we don't support text searching using expression index
> than remove default_text_search_config. Anyway, I don't feel myself
> responisble for such important problem. We need more feedback from 
> users.

Well, I am waiting for other hackers to get involved, but if they don't,
I have to evaluate it myself on the email lists.

> > If we are going to keep it, I need someone to explain why my comments
> > above are wrong.  If I am right, someone has to remove
> > default_text_search_config from the patch.   I can do the documentation.
> 
> I'm in conference and then will be busy writing my applications and
> earning money, Teodor is in vacation. I don't want to do 
> hasty conclusion, since we're very tired to change our patch from 
> one solution to another. We need consensus of developers and users.
> I'm almost exhausted and have  no time  to continue this discussion.
> 
> Would you be so kind to write separate post about this problem and
> call -hackers and -general for feedback. Let's experienced users
> show their needs. We said everything and has nothing to add.

If you have no time to continue discussion and perhaps update the patch,
we can consider this patch dead for 8.3 and we can hold it for 8.4
because I can guarantee you this is going to need more discussion and
patch modification before it gets into CVS.

This patch is being treated fairly and exactly the same as every other
patch.

Should we hold the patch for 8.4?

--  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. +


pgsql-hackers by date:

Previous
From: Oleg Bartunov
Date:
Subject: Re: default_text_search_config and expression indexes
Next
From: Gregory Stark
Date:
Subject: Re: feature suggestion