Feedback-ID: ia2694551:Fastmail
Date: Mon, 17 Mar 2025 09:44:20 +0100
From: =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@alvh.no-ip.org>
To: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>, Sami Imseih <samimseih@gmail.com>,
	Julien Rouhaud <rjuju123@gmail.com>, Kirill Reshke <reshkekirill@gmail.com>,
	Sergei Kornilov <sk@zsrv.org>, yasuo.honda@gmail.com, tgl@sss.pgh.pa.us,
 smithpb2250@gmail.com,
	michael@paquier.xyz, nathandbossart@gmail.com, stark.cfm@gmail.com,
	geidav.pg@gmail.com, marcos@f10.com.br, robertmhaas@gmail.com,
 david@pgmasters.net,
	pgsql-hackers@postgresql.org, pavel.trukhanov@gmail.com,
 Sutou Kouhei <kou@clear-code.com>
Subject: Re: pg_stat_statements and "IN" conditions
Message-ID: <202503170844.j7tmqg22dq6o@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <djrvh7zqsceg3o4fy6lwoyhbvsqlgwg5eoauxjm5foqfb3wy6k@ysgqdhvbno7x>
Archived-At: 
 <https://www.postgresql.org/message-id/202503170844.j7tmqg22dq6o%40alvherre.pgsql>
Precedence: bulk

On 2025-Mar-17, Dmitry Dolgov wrote:

> I'm afraid there is a disagreement about this part of the feedback. I'm
> not yet convinced about the idea suggested over there (treating mutable
> functions in the same way as constants) and not planning to change
> anything, at least not in the current version of the patch.

I have to admit that I am leaning towards removing the immutability
constraint.  The reason is that we already require the function to be
boostrapped (due to the OID test) and to have implicit cast form, so
that limits which functions are recognized; the only ones there that are
not immutable are:


         castsource          │        casttarget        │                 castfunc                 
─────────────────────────────┼──────────────────────────┼──────────────────────────────────────────
 text                        │ regclass                 │ regclass(text)
 character varying           │ regclass                 │ regclass(text)
 date                        │ timestamp with time zone │ timestamptz(date)
 time without time zone      │ time with time zone      │ timetz(time without time zone)
 timestamp without time zone │ timestamp with time zone │ timestamptz(timestamp without time zone)

Looking at this list, it seems rather random to me to say that we should
not squash arrays with types using these casts.  Should we really
consider two queries to be different because they run with different
search_path or TimeZone settings?

But kindly do not submit a new version of the patch, as I already have
some changes of my own (mostly on removing the term "merge" from code
and comments to replace with "squash", as well as adding some more
comments).  I'll post it soon.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/