From: | Teodor Sigaev <teodor(at)stack(dot)net> |
---|---|
To: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
Cc: | "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: tsearch bug in 7.2.1? |
Date: | 2002-08-16 09:28:29 |
Message-ID: | 3D5CC5BD.2050601@stack.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
No 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
From | Date | Subject | |
---|---|---|---|
Next Message | Mario Weilguni | 2002-08-16 09:50:57 | pg_restore and user defined types, several other pg_restore problems |
Previous Message | Vince Vielhaber | 2002-08-16 09:21:45 | Re: Open 7.3 items |