Re: queryId constant squashing does not support prepared statements - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: queryId constant squashing does not support prepared statements
Date
Msg-id aDEkCs3BefgtysVV@paquier.xyz
Whole thread Raw
In response to Re: queryId constant squashing does not support prepared statements  (Sami Imseih <samimseih@gmail.com>)
Responses Re: queryId constant squashing does not support prepared statements
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Fixing memory leaks in postgres_fdw
Next
From: Tatsuo Ishii
Date:
Subject: Re: Retiring some encodings?