A bug search for all tags "foo bar -*" never returns any bug

Bug #619908 reported by Abel Deuring on 2010-08-18
38
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Low
Unassigned

Bug Description

If a users enters the tag expression "foo -*" and selects the "find all tags" option, the search result will always be empty. The SQL expression returned by build_tag_search_clause() is in this case:

    BugTask.bug IN (SELECT bug from BugTag WHERE tag = 'foo') AND BugTask.bug NOT IN (SELECT bug from BugTag)

Formally, this is correct, but from a DWIM viewpoint it would be better to return those bugs having the tag 'foo' but no other tags. (Note that we already do a bit of DWIM for searches like 'foo -bar -*' for the "find any tag" search variant: In this case, we silently drop the '*' term.

Abel Deuring (adeuring) wrote :

Anyway, if we want to keep the current behaviour, we should short-cut the long expression to a simple FALSE. (Or is Postgresql clever enough to figure this out automatically?)

1 comments hidden view all 185 comments

comment text

Abel Deuring (adeuring) on 2010-09-07
visibility: public → private
15 comments hidden view all 185 comments
Abel Deuring (adeuring) wrote :

sorry for adding and deleting all the bug attachments. I need to check a few problems with adding attachments via the webservice, and staging is at present down.

Abel Deuring (adeuring) wrote :

comment text

Deryck Hodge (deryck) on 2010-09-08
Changed in malone:
status: New → Triaged
importance: Undecided → Low
164 comments hidden view all 185 comments
Gavin Panella (allenap) wrote :

My feeling is that the current behaviour is the not too suprising, but
is perhaps not very "human". Changing it as Abel suggests would, I
think, make the feature more useful without affecting any existing
use-cases.

> Anyway, if we want to keep the current behaviour, we should
> short-cut the long expression to a simple FALSE. (Or is Postgresql
> clever enough to figure this out automatically?)

ISTR that Postgres is clever enough to do this for us, so I kept the
Python implementation as clean and symmetrical as I could.

Deryck Hodge (deryck) on 2010-11-30
visibility: private → public
Displaying first 40 and last 40 comments. View all 185 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers