Re: Version 17.6 changed how similar works compared to version 17.5
От | Laurenz Albe |
---|---|
Тема | Re: Version 17.6 changed how similar works compared to version 17.5 |
Дата | |
Msg-id | ed3621c23c0d08c46a3bae48d8da2d9e33c6b041.camel@cybertec.at обсуждение исходный текст |
Ответ на | Version 17.6 changed how similar works compared to version 17.5 (Stephan Springl <springl-psql@bfw-online.de>) |
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: