From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> |
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:14:46 |
Message-ID: | 4422.1186640086@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
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.
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,
I want another function that has a fuzzier weighted definition,
because I think that'll be what most applications actually want.
The OP was asking for a version that has a strict OR behavior.
I'm not sure if that's really interesting or not ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Oleg Bartunov | 2007-08-09 06:30:37 | Re: tsearch2: plainto_tsquery() with OR? |
Previous Message | Oleg Bartunov | 2007-08-09 06:02:20 | Re: tsearch2: plainto_tsquery() with OR? |