Fix ts_headline() to handle ORs and phrase queries more honestly.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 19 Jan 2023 21:21:44 +0000 (16:21 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 19 Jan 2023 21:21:44 +0000 (16:21 -0500)
commit5a617d75d3b31414f378dd764a11db1a08fa79bb
tree0c366969873581f99ca2c99b50c6d21eab11c6bd
parent44e9e34266efd42901bf7b12552f2033972d70b7
Fix ts_headline() to handle ORs and phrase queries more honestly.

This patch largely reverts what I did in commits c9b0c678d and
78e73e875.  The maximum cover length limit that I added in 78e73e875
(to band-aid over c9b0c678d's performance issues) creates too many
user-visible behavior discrepancies, as complained of for example in
bug #17691.  The real problem with hlCover() is not what I thought
at the time, but more that it seems to have been designed with only
AND tsquery semantics in mind.  It doesn't work quite right for OR,
and even less so for NOT or phrase queries.  However, we can improve
that situation by building a variant of TS_execute() that returns a
list of match locations.  We already get an ExecPhraseData struct
representing match locations for the primitive case of a simple match,
as well as one for a phrase match; we just need to add some logic to
combine these for AND and OR operators.  The result is a list of
ExecPhraseDatas, which hlCover can regard as having simple AND
semantics, so that its old algorithm works correctly.

There's still a lot not to like about ts_headline's behavior, but
I think the remaining issues have to do with the heuristics used
in mark_hl_words and mark_hl_fragments (which, likewise, were not
revisited when phrase search was added).  Improving those is a task
for another day.

Patch by me; thanks to Alvaro Herrera for review.

Discussion: https://postgr.es/m/840.1669405935@sss.pgh.pa.us
src/backend/tsearch/wparser_def.c
src/backend/utils/adt/tsvector_op.c
src/include/tsearch/ts_utils.h
src/test/regress/expected/tsearch.out
src/test/regress/sql/tsearch.sql