From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Sami Imseih <samimseih(at)gmail(dot)com> |
Cc: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Junwang Zhao <zhjwpku(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: queryId constant squashing does not support prepared statements |
Date: | 2025-05-27 00:58:34 |
Message-ID: | aDUOOjTIRoTY5vkZ@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, May 24, 2025 at 09:35:24AM -0500, Sami Imseih wrote:
> 2. If we have 1 or more squashed lists, then we can't guarantee
> the $n parameter as was supplied by the user and we simply rename
> the $n starting from 1.
>
> therefore, a user supplied query like this:
> ```
> select where $5 in ($1, $2, $3) and $6 = $4 and 1 = 2
> ```
>
> will be normalized to:
> ```
> select where $1 in ($2 /*...*/) and $3 = $4 and $5 = $6
> ```
>
> To accomplish this, we will need to track the locations of
> external parameters to support the 2nd case, because we need
> to re-write the original location of the parameter with
> the new value. I played around with this this morning and
> it works as I described above. Any concerns with the
> behavior described above?
That would be OK by me. Not having gaps in the parameter numbers of
the normalized query just feels just like the natural thing to have in
the data reported by PGSS.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | jian he | 2025-05-27 02:03:58 | Re: Prevent internal error at concurrent CREATE OR REPLACE FUNCTION |
Previous Message | Michael Paquier | 2025-05-27 00:51:14 | Re: Persist injection points across server restarts |