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.96) (envelope-from ) id 1vQoWs-000xiN-2R for pgsql-bugs@arkaria.postgresql.org; Wed, 03 Dec 2025 15:12:31 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vQoWq-00Dtt4-1s for pgsql-bugs@arkaria.postgresql.org; Wed, 03 Dec 2025 15:12:28 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vQoWq-00Dtsv-11 for pgsql-bugs@lists.postgresql.org; Wed, 03 Dec 2025 15:12:28 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vQoWn-002wbh-32 for pgsql-bugs@lists.postgresql.org; Wed, 03 Dec 2025 15:12:27 +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 5B3FC7P4640026; Wed, 3 Dec 2025 10:12:08 -0500 From: Tom Lane To: Laurenz Albe cc: Heikki Linnakangas , adam.warland@infor.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #19341: REPLACE() fails to match final character when using nondeterministic ICU collation In-reply-to: <0bbe14779f2c37e5a2fbd514861ebedaf8f53df6.camel@cybertec.at> References: <19341-1d9a22915edfec58@postgresql.org> <60b467ac47d5c6bbb9c21c3bdfecce8e5de60cda.camel@cybertec.at> <6935ea1e-cfb1-400b-9057-3d43b55d621a@iki.fi> <9f47c6b24d6cf59002603caf19b8b3f4854176be.camel@cybertec.at> <375807.1764696352@sss.pgh.pa.us> <464a14fcbee9567ace136716714b8c18f9bd87fb.camel@cybertec.at> <436944.1764708826@sss.pgh.pa.us> <0bbe14779f2c37e5a2fbd514861ebedaf8f53df6.camel@cybertec.at> Comments: In-reply-to Laurenz Albe message dated "Wed, 03 Dec 2025 08:51:22 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <640024.1764774727.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Wed, 03 Dec 2025 10:12:07 -0500 Message-ID: <640025.1764774727@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Laurenz Albe writes: > On Tue, 2025-12-02 at 15:53 -0500, Tom Lane wrote: >> Looking at the code overall, I wonder if the outer loop doesn't have >> the same issue.  The comments claim that we should be able to handle >> zero-length matches, but if the overall haystack is of length zero, >> we will fail to check for such a match. > If you can find zero-length matches at all, you could find a > zero-length match in a non-empty haystack. Perhaps the function is > never called with an empty haystack... After further thought, it seems to me that this comment is an unjustified extrapolation from what Peter actually said, which was that the match substring could be physically shorter than the needle. Which is certainly true, for instance case-folding or accent-stripping might shorten the string. But it doesn't follow that a nonempty needle could ever match an empty substring; and that does not seem like it could be sane behavior to me. We're considering string comparison here, not regexes. We do require callers to eliminate the empty-needle case, and given that I think we could assume that match substrings must be at least 1 byte long. That assumption is what justifies the current API for these functions, and perhaps we can also simplify this loop by using it. regards, tom lane