Re: Please, apply patch

Patch applied. Thanks.

---------------------------------------------------------------------------

Teodor Sigaev wrote:
> Please, apply patch for tsearch to current CVS.
>
> Patch resolve ERROR problem for non-goog query_txt.
>
> Teodor Sigaev wrote:
> > Now you can use:
> > regression=# select 'the'::mquery_txt;
> > ERROR: Your query contained only stopword(s), ignored
> > regression=# select 'good'::mquery_txt;
> > mquery_txt
> > ------------
> > 'good'
> > (1 row)
> >
> > I suggest:
> > 1.
> > regression=# select 'the'::mquery_txt;
> > NOTICE: Your query contained only stopword(s), ignored
> > mquery_txt
> > -------------
> >
> > (1 row)
> > 2. any operation with void query returns false:
> > select t from tbl where t ## 'the';
> > NOTICE: Your query contained only stopword(s), ignored
> > tbl
> > -----
> > (0 row)
> >
> >
> >
> >
> >
> > 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...
> >>
> >> Chris
> >>
> >>
> >>> -----Original Message-----
> >>> From: pgsql-hackers-owner(at)postgresql(dot)org
> >>> [mailto:pgsql-hackers-owner(at)postgresql(dot)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
> >>>
> >>
> >>
> >>
> >> ---------------------------(end of broadcast)---------------------------
> >> TIP 3: if posting/reading through Usenet, please send an appropriate
> >> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> >> message can get through to the mailing list cleanly
> >>
> >
> >
>
>
> --
> Teodor Sigaev
> teodor(at)stack(dot)net
>

[ application/gzip is not supported, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073