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