Message-ID: <b4b25c91f05f0be8fb7072c8dbf9d4ca6062b303.camel@cybertec.at>
Subject: Re: SIMILAR TO expressions translate wildcards where they shouldn't
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael@paquier.xyz>, pgsql-bugs@lists.postgresql.org
Date: Tue, 27 May 2025 23:39:02 +0200
In-Reply-To: <1101508.1748357652@sss.pgh.pa.us>
References: <16ab039d1af455652bdf4173402ddda145f2c73b.camel@cybertec.at>
	 <aC_K7JPXF0AdPZqB@paquier.xyz> <aC_p7b5H6pLICU_e@paquier.xyz>
	 <5498224d1d5a6a3be7f29ae7725f76162d48372f.camel@cybertec.at>
	 <aDVUWaoZg8cW3B9x@paquier.xyz>
	 <37584c1321b984a0c5c05d213ef70b869d95a12a.camel@cybertec.at>
	 <1101508.1748357652@sss.pgh.pa.us>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.56.2 (3.56.2-1.fc42) 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/b4b25c91f05f0be8fb7072c8dbf9d4ca6062b303.camel%40cybertec.at>
Precedence: bulk

On Tue, 2025-05-27 at 10:54 -0400, Tom Lane wrote:
> Laurenz Albe <laurenz.albe@cybertec.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?
>=20
> > Thank you; I think that is good to go.
>=20
> Code changes look good, but I think the test cases are too cute:
>=20
> +EXPLAIN (VERBOSE, COSTS OFF) SELECT (SELECT '') SIMILAR TO '_[_[:alpha:]=
_]_';
> +                          QUERY PLAN                          =20
> +---------------------------------------------------------------
> + Result
> +   Output: ((InitPlan 1).col1 ~ '^(?:.[_[:alpha:]_].)$'::text)
> +   InitPlan 1
> +     ->  Result
> +           Output: ''::text
> +(5 rows)
>=20
> This will break whenever somebody decides it's worth optimizing
> a sub-select that looks like that.  I'd suggest following the
> pattern
>=20
> explain (costs off) select * from text_tbl where f1 similar to 'z';
>             QUERY PLAN           =20
> ----------------------------------
>  Seq Scan on text_tbl
>    Filter: (f1 ~ '^(?:z)$'::text)
> (2 rows)
>=20
> which is both less noisy and less likely to change in future.

That's a good point.
I originally considered EXPLAIN (GENERIC_PLAN), but that would only
backpatch so far.

Yours,
Laurenz Albe