Skip site navigation (1) Skip section navigation (2)

Re: Poorly designed tsearch NOTICEs

From: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Teodor Sigaev <teodor(at)sigaev(dot)ru>
Subject: Re: Poorly designed tsearch NOTICEs
Date: 2007-11-28 04:44:34
Message-ID: 200711272344.34929.xzilla@users.sourceforge.net (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tuesday 27 November 2007 19:03, Tom Lane wrote:
> Last month I complained:
> > regression=# SELECT plainto_tsquery('the any');
> > NOTICE:  query contains only stopword(s) or doesn't contain lexeme(s),
> > ignored plainto_tsquery
> > -----------------
> >
> > (1 row)
> >
> > regression=# select ''::tsquery;
> > NOTICE:  tsearch query doesn't contain lexeme(s): ""
> >  tsquery
> > ---------
> >
> > (1 row)
> >
> > IMHO, it's really bad design to have this sort of NOTICE emitted by
> > tsquery input.  Even if an application uses numnode() or querytree() or
> > something similar to detect bogus queries, it's going to have its logs
> > cluttered with these notices.
> >
> > I could see having the @@ operator emit the notice if the query is
> > actually used for searching --- though I'm not quite sure how to get it
> > to come out only once per query ... maybe we could put it into the index
> > consistent() functions somehow?
>
> I experimented with this and found out that it works all right for GIN
> indexes, if the NOTICE is put into gin_extract_query(); that seems to be
> called just once per GIN index search.  However, the only possible place
> to put it in GIST tsearch support would be in the consistent() routines,
> and that's no good because those will be called once per entry on the
> index's root page --- so you get multiple copies of the NOTICE.
>
> So it seems that the practical alternatives are:
>
> 1. Leave these notices where they are.  Expect complaints from people
> who would rather not have their logs cluttered with 'em.
>
> 2. Remove the notices altogether.  Expect complaints from people who
> get no matches on queries that they don't realize are all-stopwords.
>
> 3. Remove the notices from the input routines, and put one into
> gin_extract_query only.  We'll still get complaints as in #2, but
> only from people using GIST indexes or no index at all for searching.
>
> None of these are really terribly attractive, but I'm kinda leaning
> to #2 myself.  I'm not convinced that it's the province of the DB to be
> issuing messages like this.  In a lot of common scenarios, NOTICEs
> aren't going to be seen by the actual person entering the query anyway,
> because there are layers of software between him and the DB.  All they
> will accomplish is to bloat some logs somewhere.
>
> Comments?

I would lean toward #1 since it seems to be closest to the behavior from 
previous releases. 

-- 
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-11-28 04:50:08
Subject: Re: Poorly named support routines for GIN tsearch index opclasses
Previous:From: Bruce MomjianDate: 2007-11-28 04:25:07
Subject: Re: Still a NOTICE in dict_thesaurus.c

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group