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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: SIMILAR TO expressions translate wildcards where they shouldn't
Date: 2025-05-27 14:54:12
Message-ID: 1101508.1748357652@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> writes:
> On Tue, 2025-05-27 at 14:57 +0900, Michael Paquier wrote:
>> With some tweaks and the tests reworked, I am finishing with the
>> reviewed version attached. What do you think?

> Thank you; I think that is good to go.

Code changes look good, but I think the test cases are too cute:

+EXPLAIN (VERBOSE, COSTS OFF) SELECT (SELECT '') SIMILAR TO '_[_[:alpha:]_]_';
+ QUERY PLAN
+---------------------------------------------------------------
+ Result
+ Output: ((InitPlan 1).col1 ~ '^(?:.[_[:alpha:]_].)$'::text)
+ InitPlan 1
+ -> Result
+ Output: ''::text
+(5 rows)

This will break whenever somebody decides it's worth optimizing
a sub-select that looks like that. I'd suggest following the
pattern

explain (costs off) select * from text_tbl where f1 similar to 'z';
QUERY PLAN
----------------------------------
Seq Scan on text_tbl
Filter: (f1 ~ '^(?:z)$'::text)
(2 rows)

which is both less noisy and less likely to change in future.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Chris Gooch 2025-05-27 16:13:07 RE: [EXT] Re: GSS Auth issue when user member of lots of AD groups
Previous Message Laurenz Albe 2025-05-27 10:24:33 Re: SIMILAR TO expressions translate wildcards where they shouldn't