Re: tsearch bug in 7.2.1?

Ross and Chris,

I was reading too fast :-)
The problem is actually more complex:
We have to distinguish 4 cases when Query could returns zero result:

1. normal - there are no such words
2. query consists of stop-words only
3. query consists of lexems of non-indexed clasess (specified in parser currently)
4. combination of 2 and 3

Ideally, we want to inform middleware all these cases.

Oleg
On Thu, 15 Aug 2002, Ross J. Reedstrom wrote:

> On Thu, Aug 15, 2002 at 11:59:20AM +0300, Oleg Bartunov wrote:
> > tsearch has compiled-in stop-list, it's currently just not flexible
> > as OpenFTS does. We plan to move most functionality to tsearch but
> > currently have no time. Feel free to join us to speedup tsearch
> > development.
>
> Oleg -
> I think Chris's issue might be the same one I ran into just last night.
> (BTW, thanks for tsearch and the OpenFTS work, it's really great)
> My problem is that queries with only stopwords throw an ERROR, rather
> than a WARNING or NOTICE. This means We've got to deal with catching an
> exception so our middleware doesn't spew ugly errors and tracebacks at
> our endusers, and I've got to deal with cleaning up the transaction.
>
> Having the behavior be "issue a notice and return no match" would give
> us a reasonably functional interface: if I don't implement reading the
> NOTICE, I get confused users ('huh? "the" doesn't match anything?')
> rather than irate users ('Your search interface sucks! It keeps
> crashing!')
>
> Oh, well, off to implement some try: catch: logic.
>
> Ross
>

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83