Re: [BUGS] BUG #14552: tsquery converts AND operator into OR when nested inside OR operations

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [BUGS] BUG #14552: tsquery converts AND operator into OR when nested inside OR operations
Дата
Msg-id 11187.1487381065@sss.pgh.pa.us
обсуждение исходный текст
Ответ на [BUGS] BUG #14552: tsquery converts AND operator into OR when nested insideOR operations  (bjorn@eventmy.com)
Список pgsql-bugs
bjorn@eventmy.com writes:
> Working correctly, no results: 
> SELECT ts_rank(to_tsvector('lets eat a cat'), ('fat & bat | rat'::tsquery &&
> 'cat'::tsquery));
>  ts_rank
> ---------
>    1e-20
> (1 row)

> Should also yield no results:
> SELECT ts_rank(to_tsvector('lets eat a fat cat'), ('fat & bat |
> rat'::tsquery && 'cat'::tsquery));
>   ts_rank
> -----------
>  0.0991032
> (1 row)

> Is this intended behavior?

Don't see what you find surprising about it?  ts_rank() is documented as

    Ranks vectors based on the frequency of their matching lexemes.

The first example has one lexeme that matches the query's lexemes,
the second has two.  It should get a higher ranking.

If you want to know whether the tsvector formally matches the query,
you should be applying the @@ operator.  ts_rank() is not a binary
yes/no thing, it's trying to identify stuff that is more or less
relevant to the query's terms.  At least from the documentation,
I'd suspect it pays no attention to the operators in the query.

In short: the intended use of ts_rank() is for sorting values that
have already passed an @@ match.  It's not a substitute for @@.

            regards, tom lane


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

В списке pgsql-bugs по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: [BUGS] BUG #14494: Regression - Null arrays are not queryable
Следующее
От: "Casey Witt"
Дата:
Сообщение: Re: [BUGS] BUG #14546: "point" type does not work with "IS DISTINCT"