From: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | cluster <skrald(at)amossen(dot)dk>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: tsearch2: plainto_tsquery() with OR? |
Date: | 2007-08-09 06:30:37 |
Message-ID: | Pine.LNX.4.64.0708091016220.18739@sn.sai.msu.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, 9 Aug 2007, Tom Lane wrote:
> Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> writes:
>> " neither a strict AND nor a strict OR" is not a good foundation for
>> database text search API.
>
> Maybe not, but the Google boys have sure done well without telling
> anyone what their algorithms are.
>
> My feeling is that if you use an API that involves explicit AND and OR
> operators (to_tsquery does this if I'm not mistaken) then you should
> get a result that matches those semantics exactly. But the other
right, to_tsquery does exact and predicted matching.
> behavior that people want is "here's some words, get me a weighted
> result", and if the weighting improves from time to time that's OK.
> We need to provide that API too.
I think I understand. It's called non-exact (approximate) matching,
when by default you search documents containing ALL words in query, weighted
in usual way, and then append documents, which contains either words in query
weighted by the number of words found. It's useful for rare words.
>
> Whether plainto_tsquery() should be defined that way, I'm not sure.
> Maybe there's enough historical behavior behind it that we should
> stick with defining it as "strict AND of these words". But if so,
yeah, this was requested by people to have simple search interface.
> I want another function that has a fuzzier weighted definition,
> because I think that'll be what most applications actually want.
Tom, approximate search is a good challenge, it's a subject of research of
people from IR world. It's what I always wanted to do, but we have to
support our families and no company was interested in such kind of search,
unfortunately.
>
> The OP was asking for a version that has a strict OR behavior.
> I'm not sure if that's really interesting or not ...
I understood now, what he wanted. He don't want to parse search query,
he wanted simplicity of plainto_tsquery() and ability for boolean search
of to_tsquery(). As I already said, people have their own query language
wrappers on top of to_tsquery. Unfortunately, we have no consensus here.
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru)
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-08-09 06:40:07 | Re: tsearch2: plainto_tsquery() with OR? |
Previous Message | Tom Lane | 2007-08-09 06:14:46 | Re: tsearch2: plainto_tsquery() with OR? |