Re: Latest patches break one of our unit-test, related to RLS
Dominique Devienne <ddevienne@gmail.com>
From: Dominique Devienne <ddevienne@gmail.com>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: pgsql-general@postgresql.org
Date: 2025-09-12T13:24:29Z
Lists: pgsql-general
On Fri, Sep 12, 2025 at 3:11 PM Dominique Devienne <ddevienne@gmail.com> wrote: > On Fri, Sep 12, 2025 at 2:45 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote: > > You don't show us that data that match the pattern in 17.5, but > > not in 17.6. Unless you show us a counterexample, I'd say that > > the behavior in 17.6 is correct. I've reread https://www.postgresql.org/docs/current/functions-matching.html#FUNCTIONS-SIMILARTO-REGEXP and especially: > According to the SQL standard, omitting ESCAPE means there is no escape character (rather than defaulting to a backslash), and a zero-length ESCAPE value is disallowed. PostgreSQL's behavior in this regard is therefore slightly nonstandard. and also > Another nonstandard extension is that following the escape character with a letter or digit provides access to the escape sequences defined for POSIX regular expressions; see Table 9.20, Table 9.21, and Table 9.22 below. Table 9.21. Regular Expression Class-Shorthand Escapes \d matches any digit, like [[:digit:]] \w matches any word character, like [[:word:]] So I don't see how my `... where v similar to 'foo[\d\w]_%'` is incorrect. So again, is this a bug / regression or not? Thanks, --DD
Commits
-
Amend recent fix for SIMILAR TO regex conversion.
- f75ff1b141a5 14.20 landed
- e09adb5b9fc9 17.7 landed
- cdf7feb96562 19 (unreleased) landed
- 9fd531534b64 15.15 landed
- 802308693f2f 18.0 landed
- 308773617d2d 13.23 landed
- 281ad4ed11d2 16.11 landed
-
Fix conversion of SIMILAR TO regexes for character classes
- e3ffc3e91d04 17.6 cited