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

On Fri, 16 Aug 2002, Christopher Kings-Lynne wrote:

> 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...

In principle, the right way is to use the same parser and the same dictionaries
for query parse, which were used in indexing ! That's the way OpenFTS does
its work, so OpenFTS knows if resulted query would be void and return
warning message *before* sending query to db. That's why we were didn't
concerned about error message returned by tsearch. But current implementation of
tsearch doesn't have api to their parser and dictionaries, so you couldn't
write parse_query(). I'd suggest to write check_query() which could use
Teodor's suggesting (see his message) - very cheap select like select 'good query'::mquery_txt;

This will works after applying patch, we'll submit if you agree with
Teodor's suggestion.

The "right way" will be possible in new incarnation of tsearch with all
functionality of OpenFTS.
Regards,    Oleg

>
> Chris
>
> > -----Original Message-----
> > From: pgsql-hackers-owner@postgresql.org
> > [mailto:pgsql-hackers-owner@postgresql.org]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
> >
>
Regards,    Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83