Re: default_text_search_config and expression indexes

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: default_text_search_config and expression indexes
Date: 2007-08-14 02:30:38
Message-ID: 200708140230.l7E2Ucv04362@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-hackers

Heikki Linnakangas wrote:
> Oleg Bartunov wrote:
> > On Wed, 8 Aug 2007, Bruce Momjian wrote:
> >> Heikki Linnakangas wrote:
> >>> If I understood correctly, the basic issue is that a tsvector datum
> >>> created using configuration A is incompatible with a tsquery datum
> >>> created using configuration B, in the sense that you won't get
> >>> reasonable results if you use the tsquery to search the tsvector, or do
> >>> ranking or highlighting. If the configurations happen to be similar
> >>> enough, it can work, but not in general.
> >>
> >> Right.
> >
> > not fair. There are many cases when one can intentionally use different
> > configurations. But I agree, this is not for beginners.
>
> Can you give an example of that?
>
> I certainly can see the need to use different configurations in one
> database, but what's the use case for comparing a tsvector created with
> configuration A against a tsquery created with configuration B?

I assume you could have a configuration with different stop words or
synonymns and compare them.

> >>> - using an expression index instead of a tsvector-field, and always
> >>> explicitly specifying the configuration, you can avoid that problem (a
> >>> query with a different configuration won't use the index). But an
> >>> expression index, without explicitly specifying the configuration, will
> >>> get corrupted if you change the default configuration.
> >>
> >> Right.
> >
> > the same problem if you drop constrain from table (accidently) and then
> > gets surprised by select results.
>
> The difference is that if you change the default configuration, you
> won't expect that your queries start to return funny results. It looks
> harmless, like changing the date style. If you drop a constraint, it's
> much more obvious what the consequences are.
>
> > We should agree that all you describe is only for DUMMY users. From
> > authors point of view I dislike your approach to treat text searching as
> > a very limited tool. But I understand that we should preserve people
> > from stupid errors.
> >
> > I want for beginners easy setup and error-prone functionality,
> > but leaving experienced users to develop complex search engines.
> > Can we have separate safe interface for text searching and explicitly
> > recommend it for beginners ?
>
> I don't see how any of the suggestions limits what you can do with it.
> If we remove the default configuration parameter, you just have to be
> explicit. If we go with the type-system I suggested, you could still add
> casts and conversion functions between different tsvector types, where
> it make sense.

I don't think the type system is workable given the ability to create
new configurations on the fly. I think the configuration must be
specified each time.

At this point, if we keep discussing the tsearch2 API we are not going
to have this in 8.3.

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

In response to

Browse pgsql-advocacy by date

  From Date Subject
Next Message Bruce Momjian 2007-08-14 02:31:25 Re: default_text_search_config and expression indexes
Previous Message Lewis Cunningham 2007-08-13 22:14:14 DBA-Village Poll

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2007-08-14 02:31:25 Re: default_text_search_config and expression indexes
Previous Message Josh Berkus 2007-08-13 23:21:45 Re: 2D partitioning of VLDB - sane or not?