From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Alex Malek <magicagent(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org, ngigi(at)at(dot)co(dot)ke |
Subject: | Re: BUG #15172: Postgresql ts_headline with <-> operator does not highlight text properly |
Date: | 2023-10-30 16:23:11 |
Message-ID: | 2425864.1698682991@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Sold! :-) Attached.
LGTM.
BTW, just for the OP's context: ts_headline was designed before
we had phrase search operators. With only AND/OR/NOT, there
aren't any location restrictions on individual words. (I recall
that we occasionally got complaints about how it shouldn't
highlight words that are supposed to NOT be there, but that was
an uncommon situation because normally you wouldn't be selecting
such a document to highlight.) So both the function's basic
algorithm and its control parameters were designed without thought
for what to do if the query restricted match locations. Maybe there's
a case for rethinking what it should do more than we already have;
but it's not clear that you can do much better without throwing out
the current set of control parameters as well as the algorithm.
See [1] for some context and discussion.
regards, tom lane
[1] https://www.postgresql.org/message-id/flat/840.1669405935%40sss.pgh.pa.us
From | Date | Subject | |
---|---|---|---|
Next Message | Andrei Lepikhov | 2023-10-31 05:05:35 | Re: BUG #18170: Unexpected error: no relation entry for relid 3 |
Previous Message | Bruce Momjian | 2023-10-30 16:00:38 | Re: BUG #15172: Postgresql ts_headline with <-> operator does not highlight text properly |