Fix strange behavior (and possible crashes) in full text phrase search.
In an attempt to simplify the tsquery matching engine, the original
phrase search patch invented rewrite rules that would rearrange a
tsquery so that no AND/OR/NOT operator appeared below a PHRASE operator.
But this approach had numerous problems. The rearrangement step was
missed by ts_rewrite (and perhaps other places), allowing tsqueries
to be created that would cause Assert failures or perhaps crashes at
execution, as reported by Andreas Seltenreich. The rewrite rules
effectively defined semantics for operators underneath PHRASE that were
buggy, or at least unintuitive. And because rewriting was done in
tsqueryin() rather than at execution, the rearrangement was user-visible,
which is not very desirable --- for example, it might cause unexpected
matches or failures to match in ts_rewrite.
As a somewhat independent problem, the behavior of nested PHRASE operators
was only sane for left-deep trees; queries like "x <-> (y <-> z)" did not
behave intuitively at all.
To fix, get rid of the rewrite logic altogether, and instead teach the
tsquery execution engine to manage AND/OR/NOT below a PHRASE operator
by explicitly computing the match location(s) and match widths for these
operators.
This requires introducing some additional fields into the publicly visible
ExecPhraseData struct; but since there's no way for third-party code to
pass such a struct to TS_phrase_execute, it shouldn't create an ABI problem
as long as we don't move the offsets of the existing fields.
Another related problem was that index searches supposed that "!x <-> y"
could be lossily approximated as "!x & y", which isn't correct because
the latter will reject, say, "x q y" which the query itself accepts.
This required some tweaking in TS_execute_ternary along with the main
tsquery engine.
Back-patch to 9.6 where phrase operators were introduced. While this
could be argued to change behavior more than we'd like in a stable branch,
we have to do something about the crash hazards and index-vs-seqscan
inconsistency, and it doesn't seem desirable to let the unintuitive
behaviors induced by the rewriting implementation stand as precedent.
Discussion: https://postgr.es/m/28215.1481999808@sss.pgh.pa.us
Discussion: https://postgr.es/m/26706.1482087250@sss.pgh.pa.us
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/89fcea1ace40bc025beea2758a80bcd56a319a6f
Modified Files
--------------
doc/src/sgml/datatype.sgml | 8 -
doc/src/sgml/textsearch.sgml | 26 +-
src/backend/utils/adt/tsginidx.c | 28 +-
src/backend/utils/adt/tsgistidx.c | 17 +-
src/backend/utils/adt/tsquery.c | 25 +-
src/backend/utils/adt/tsquery_cleanup.c | 242 +---------------
src/backend/utils/adt/tsquery_op.c | 4 +-
src/backend/utils/adt/tsvector_op.c | 477 ++++++++++++++++++++++++--------
src/include/tsearch/ts_utils.h | 31 ++-
src/test/regress/expected/tsdicts.out | 12 +-
src/test/regress/expected/tsearch.out | 40 ++-
src/test/regress/expected/tstypes.out | 298 ++++++++++----------
src/test/regress/sql/tsearch.sql | 6 +
src/test/regress/sql/tstypes.sql | 56 ++--
14 files changed, 671 insertions(+), 599 deletions(-)
