Re: Rethinking our fulltext phrase-search implementation
Artur Zakirov <a.zakirov@postgrespro.ru>
From: Artur Zakirov <a.zakirov@postgrespro.ru>
To: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Date: 2016-12-21T12:34:12Z
Lists: pgsql-hackers
Hello Tom, On 17.12.2016 21:36, Tom Lane wrote: > > 4. The transformations are wrong anyway. The OR case I showed above is > all right, but as I argued in <24331.1480199636@sss.pgh.pa.us>, the AND > case is not: > > regression=# select 'a <-> (b & c)'::tsquery; > tsquery > --------------------------- > 'a' <-> 'b' & 'a' <-> 'c' > (1 row) > > This matches 'a b a c', because 'a <-> b' and 'a <-> c' can each be > matched at different places in that text; but it seems highly unlikely to > me that that's what the writer of such a query wanted. (If she did want > that, she would write it that way to start with.) NOT is not very nice > either: If I'm not mistaken PostgreSQL 9.6 and master with patch "fix-phrase-search.patch" return false for the query: select 'a b a c' @@ 'a <-> (b & c)'::tsquery; ?column? ---------- f (1 row) I agree that such query is confusing. Maybe it is better to return true for such queries? Otherwise it seems that queries like 'a <-> (b & c)' will always return false. Then we need maybe some warning message. -- Artur Zakirov Postgres Professional: http://www.postgrespro.com Russian Postgres Company
Commits
-
Fix strange behavior (and possible crashes) in full text phrase search.
- 4e2477b7b8b6 9.6.2 landed
- 89fcea1ace40 10.0 landed
-
Fix handling of phrase operator removal while removing tsquery stopwords.
- 2604438472c8 10.0 landed
- 3f07eff10479 9.6.2 landed