Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qxV2t-001Geb-B4 for pgsql-bugs@arkaria.postgresql.org; Mon, 30 Oct 2023 16:23:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qxV2r-00FWtN-RS for pgsql-bugs@arkaria.postgresql.org; Mon, 30 Oct 2023 16:23:17 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qxV2r-00FWtF-JS for pgsql-bugs@lists.postgresql.org; Mon, 30 Oct 2023 16:23:17 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qxV2o-003qqI-QB for pgsql-bugs@lists.postgresql.org; Mon, 30 Oct 2023 16:23:17 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 39UGNB1I2425865; Mon, 30 Oct 2023 12:23:11 -0400 From: Tom Lane To: Bruce Momjian cc: Alex Malek , pgsql-bugs@lists.postgresql.org, ngigi@at.co.ke Subject: Re: BUG #15172: Postgresql ts_headline with <-> operator does not highlight text properly In-reply-to: References: <152461454026.19805.6310947081647212894@wrigleys.postgresql.org> <1995601.1698526000@sss.pgh.pa.us> <2140529.1698594815@sss.pgh.pa.us> <2420641.1698679946@sss.pgh.pa.us> Comments: In-reply-to Bruce Momjian message dated "Mon, 30 Oct 2023 12:00:38 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2425863.1698682991.1@sss.pgh.pa.us> Date: Mon, 30 Oct 2023 12:23:11 -0400 Message-ID: <2425864.1698682991@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Bruce Momjian 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