Re: default_text_search_config and expression indexes

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, 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-10 13:57:06
Message-ID: 46BC6EB2.7090404@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-hackers

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?

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

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-advocacy by date

  From Date Subject
Next Message Heikki Linnakangas 2007-08-10 13:57:39 Re: default_text_search_config and expression indexes
Previous Message Joshua D. Drake 2007-08-10 13:47:32 Re: Quality of email postings

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2007-08-10 13:57:39 Re: default_text_search_config and expression indexes
Previous Message Pavel Stehule 2007-08-10 11:26:40 regexp_split_to_array hangs backend