From: Tom Lane <tgl@sss.pgh.pa.us>
To: Laurenz Albe <laurenz.albe@cybertec.at>
cc: Heikki Linnakangas <hlinnaka@iki.fi>, 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: <464a14fcbee9567ace136716714b8c18f9bd87fb.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>
Comments: In-reply-to Laurenz Albe <laurenz.albe@cybertec.at>
	message dated "Tue, 02 Dec 2025 18:51:14 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <436943.1764708826.1@sss.pgh.pa.us>
Date: Tue, 02 Dec 2025 15:53:46 -0500
Message-ID: <436944.1764708826@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/436944.1764708826%40sss.pgh.pa.us>
Precedence: bulk

Laurenz Albe <laurenz.albe@cybertec.at> writes:
> On Tue, 2025-12-02 at 12:25 -0500, Tom Lane wrote:
>> You need to rearrange the loop logic so that we won't attempt to
>> increment test_end that last time through.  Perhaps a for-loop
>> isn't the best way to write it.

> Right.  The attached patch v3 turns it into a while loop to avoid
> the problem.

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.

Also, since we have haystack <= haystack_end as a starting condition,
I think both loops could omit the initial test.  I'd be inclined
to code them like

	test_ptr = start point;
	for (;;)
	{
		...
		if (test_ptr >= haystack_end)
			break;
		test_ptr += pg_mblen(test_ptr);
	}

On the other hand ... is that comment really right about zero-length
match being possible?  If it is, the API for this function is in
need of redesign, because callers that try to find "the next match"
would go into an infinite loop re-finding the same zero-length
match over and over.

			regards, tom lane