On Fri, 2025-09-12 at 15:45 +0200, Stephan Springl wrote:
> version 17.6 changed how similar works compared to version 17.5.
>
> With file f as
> cat >f <<END
> drop table t;
> create table t (p varchar (1));
> insert into t values ('_');
> select * from t;
> select * from t where p similar to '[\_]%';
> END
>
> psql -f f
>
> gives:
>
> DROP TABLE
> CREATE TABLE
> INSERT 0 1
> p
> ---
> _
> (1 row)
>
> p
> ---
> (0 rows)
>
> The expression with similar does not find the row. With version 17.5, the row
> was found, as wanted.
>
> Reverting commit e3ffc3e91d04579240fb54a96f9059b246488dce
> "Fix conversion of SIMILAR TO regexes for character classes"
> brings back the previous behavior. The patch does not take account of the
> first character in a character class being escaped. In this case it skips
> the closing ']' of the caracter class. "[_]%" as similar expression gets
> translated to "^(?:[\_]%)$" as a regular expression. Version 17.5
> generates "^(?:[\_].*)$" as regular expression.
You are right, that is a bug. It was reported independently in [1].
Your analysis is correct, but I don't think that your fix is the right one.
Could you try my patch in [2] and see if that works for you?
Yours,
Laurenz Albe
[1]: https://postgr.es/m/flat/CAFCRh-8NwJd0jq6P%3DR3qhHyqU7hw0BTor3W0SvUcii24et%2BzAw%40mail.gmail.com
[2]: https://postgr.es/m/2c58dcdba889f5b28df5ad9d21b5ea2d0ac63a9a.camel%40cybertec.at
