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

[Abel Deuring]

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)]

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?)

[Abel Deuring (adeuring)]

comment text

[Abel Deuring (adeuring)]

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)]

comment text

[Gavin Panella (allenap)]

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.