Re: queryId constant squashing does not support prepared statements

On Fri, May 23, 2025 at 08:05:47PM -0500, Sami Imseih wrote:
> Since we assign new parameter symbols based on the highest external param
> from the original query, as stated in the docs [0] "The parameter
> symbols used to replace
> constants in representative query texts start from the next number after the
> highest $n parameter in the original query text", we could have gaps
> in assigning
> symbol values, such as the case below.
>
> ```
> test=# select where 1 in ($1, $2, $3) and 1 = $4
> test-# \bind 1 2 3 4
> test-# ;
> --
> (0 rows)
>
> test=# select query from pg_stat_statements;
>                      query
> ------------------------------------------------
>  select where $5 in ($6 /*, ... */) and $7 = $4
> ```
>
> I don't think there is much we can do here, without introducing some serious
> complexity. I think the docs make this scenario clear.

In v17, we are a bit smarter with the numbering, with a normalization
giving the following, starting at $1:
select where $5 in ($1, $2, $3) and $6 = $4

So your argument about the $n parameters is kind of true, but I think
the numbering logic in v17 to start at $1 is a less-confusing result.
I would imagine that the squashed logic should give the following
result on HEAD in this case if we want a maximum of consistency with
the squashing of the IN elements taken into account:
select where $3 in ($1 /*, ... */) and $4 = $2

Starting the count of the parameters at $4 would be strange.
--
Michael