Ross - maybe we could work on a little function for tsearch - parse_query() or something like that. It could return true or false depending on whether it would cause tsearch to error or not...
Chris > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Ross J. > Reedstrom > Sent: Friday, 16 August 2002 4:59 AM > To: Oleg Bartunov > Cc: Christopher Kings-Lynne; Hackers > Subject: Re: [HACKERS] tsearch bug in 7.2.1? > > > 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 > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
