Re: queryId constant squashing does not support prepared statements

Michael Paquier <michael@paquier.xyz> writes:
> On Thu, May 01, 2025 at 03:57:16PM -0500, Sami Imseih wrote:
>> I think what we should really allow the broader scope of expressions that
>> are allowed via prepared statements, and this will make this implementation
>> consistent between prepared vs non-prepared statements. I don't see why
>> not. In fact, when we are examining the ArrayExpr, I think the only
>> thing we should
>> not squash is if we find a Sublink ( i.e. SELECT statement inside the array ).

> Likely so.  I don't have anything else than Sublink in mind that would
> be worth a special case..

I think this is completely wrong.  As simple examples, there is
nothing even a little bit comparable between the behaviors of

	t1.x IN (1, 2, 3)

	t1.x IN (1, 2, t2.y)

	t1.x IN (1, 2, random())

Squashing these to look the same would be doing nobody any favors.

I do agree that treating PARAM_EXTERN Params the same as constants
for this purpose is a reasonable thing to do, on three arguments:

1. A PARAM_EXTERN Param actually behaves largely the same as a Const
so far as a query is concerned: it does not change value across
the execution of the query.  (This is not true of other kinds of
Params.)

2. It's very much dependent on the client-side stack whether a given
value that is constant in the mind of the application will be passed
to the backend as a Const or a Param.  (This is okay because #1.)

3. Even if the value is passed as a Param, the planner might replace
it by a Const by means of generating a custom query plan.

So the boundary between PARAM_EXTERN Params and Consts is actually
mighty squishy, and thus I think it makes sense for pg_stat_statements
to mash them together.  But this logic does not extend to Vars or
function calls or much of anything else.

Maybe in the future we could have a discussion about whether
expressions involving only Params, Consts, and immutable functions
(say, "$1 + 1") could be mashed as though they were constants, on
the grounds that they'd have been reduced to a single constant if the
planner had chosen to generate a custom plan.  But I think it's too
late to consider that for v18.  I'd be okay with the rule "treat any
list of Consts and PARAM_EXTERN Params the same as any other" for v18.

I also agree with Alvaro that this discussion doesn't justify a
revert.  If the pre-v18 behavior wasn't chiseled on stone tablets,
the new behavior isn't either.  We can improve it some more later.

			regards, tom lane