Re: Latest patches break one of our unit-test, related to RLS

Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> writes:
> On Fri, 2025-09-12 at 10:07 -0400, Tom Lane wrote:
>> The _ and % are not getting converted to their POSIX equivalents
>> ("." and ".*").

> Indeed, and I have to take the blame for introducing a bug in a minor
> release :^(
> The attached patch should fix the problem.

I had not particularly studied the new charclass-parsing logic.
Looking at it now, this bit further down (lines 871ff) looks
fishy:

if (pchar == ']' && charclass_start > 2)
charclass_depth--;
else if (pchar == '[')
charclass_depth++;

/*
* If there is a caret right after the opening bracket, it negates
* the character class, but a following closing bracket should
* still be treated as a normal character. That holds only for
* the first caret, so only the values 1 and 2 mean that closing
* brackets should be taken literally.
*/
if (pchar == '^')
charclass_start++;
else
charclass_start = 3; /* definitely past the start */

Should not we be setting charclass_start to 1 after incrementing
charclass_depth? That is, I'd be more comfortable if this logic
looked like

if (pchar == ']' && charclass_start > 2)
charclass_depth--;
else if (pchar == '[')
{
/* start of a nested character class */
charclass_depth++;
charclass_start = 1;
}
else if (pchar == '^')
charclass_start++;
else
charclass_start = 3; /* definitely past the start */

I haven't experimented, but it looks like this might misprocess
^ or ] at the start of a nested character class.

regards, tom lane