Re: SIMILAR TO expressions translate wildcards where they shouldn't

On Fri, May 23, 2025 at 10:10:04AM +0900, Michael Paquier wrote:
> Oh, good catch. [_[:alpha:]] and [[:alpha:]_] both that this should
> match every string made of a-zA-Z and underscores, but this is failing
> to do the job for the latter.
>
> + if (pchar != '^' && charclass_start)
> + charclass_start = false;
>
> I'm a bit puzzled by this part about '^', though, resetting the fact
> that we are in a squared bracket section with '^' treated as an
> exception. Perhaps this deserves a comment?

Ah, I see. This is just a way of saying that the caret ^ should still
be able to track the first character in the character class.

Anyway, I don't think that the tests in the patch are complete. For
example, '[[^](]' is transformed into '^(?:[[^](])$' in the SIMILAR TO
conversion with the patch, and before the patch we get
'^(?:[[^](?:])$'. Note the translation of the last parenthesis '(' to
"(?:" when inside the character class, but your patch does not
document that. AFAIU, we should not convert the parenthesis '(' while
in a multi-level character class as the patch does, but we have no
tests for it and the patch does not document this part, either.

Could it be possible to split the single SIMILAR TO expression into
multiple smaller pieces for each character that should not be
converted while inside a character class? This is hard to parse as
written in your proposal of patch.
--
Michael