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

Laurenz Albe <laurenz.albe@cybertec.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