Horton

Re: Version 17.6 changed how similar works compared to version 17.5

Laurenz Albe <laurenz.albe@cybertec.at>

View thread
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Stephan Springl <springl-psql@bfw-online.de>, pgsql-bugs@lists.postgresql.org
Date: 2025-09-12T23:41:12Z
Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Amend recent fix for SIMILAR TO regex conversion.

  2. Fix conversion of SIMILAR TO regexes for character classes

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