Our customer provides us an interesting fts puzzle - result of fts query depend on the order of arguments of @@ operator. Of course, it shouldn't be happened, that's why everebody were confused. After close look we found the problem - they used textual representation of tsvector without explicit cast to tsvector, so it was converted to tsvector again (using default_text_search_config) and it happens that tsquery contained a number 77, which was absent in the original text, but appeared in the final tsvector (there was some word at position 77). It happens only if tsquery was at right and never - when tsquery was left argument. There are three form of text search operator -
TSVECTOR @@ TSQUERY, TSQUERY @@ TSVECTOR, TEXT @@ TSQUERY, that's why postgres silently does search without complaining. Always specify explicit cast to avoid such kind of confusion.
Here are examples:
=# select 'ate:3 fat:5 mice:2 one:1 rat:6' @@ '1 & mice';
?column?
----------
t
=# select '1 & mice' @@ 'ate:3 fat:5 mice:2 one:1 rat:6';
?column?
----------
f
Explicit cast made us happy !
=# select 'ate:3 fat:5 mice:2 one:1 rat:6'::tsvector @@ '1 & mice';
?column?
----------
f
TSVECTOR @@ TSQUERY, TSQUERY @@ TSVECTOR, TEXT @@ TSQUERY, that's why postgres silently does search without complaining. Always specify explicit cast to avoid such kind of confusion.
Here are examples:
=# select 'ate:3 fat:5 mice:2 one:1 rat:6' @@ '1 & mice';
?column?
----------
t
=# select '1 & mice' @@ 'ate:3 fat:5 mice:2 one:1 rat:6';
?column?
----------
f
Explicit cast made us happy !
=# select 'ate:3 fat:5 mice:2 one:1 rat:6'::tsvector @@ '1 & mice';
?column?
----------
f