Re: tsearch bug in 7.2.1? - Mailing list pgsql-hackers

From Ross J. Reedstrom
Subject Re: tsearch bug in 7.2.1?
Date
Msg-id 20020815205911.GA16901@rice.edu
Whole thread Raw
In response to Re: tsearch bug in 7.2.1?  (Oleg Bartunov <oleg@sai.msu.su>)
Responses Re: tsearch bug in 7.2.1?  ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>)
Re: tsearch bug in 7.2.1?  (Oleg Bartunov <oleg@sai.msu.su>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: Open 7.3 issues
Next
From: "Ross J. Reedstrom"
Date:
Subject: Re: Companies involved in development