Horton

Re: queryId constant squashing does not support prepared statements

Álvaro Herrera <alvherre@kurilemu.de>

View thread
From: Álvaro Herrera <alvherre@kurilemu.de>
To: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: Sami Imseih <samimseih@gmail.com>, Michael Paquier <michael@paquier.xyz>, Junwang Zhao <zhjwpku@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-05-22T11:43:36Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix typo in comment

  2. Make query jumbling also squash PARAM_EXTERN params

  3. Fix squashing algorithm for query texts

  4. pg_stat_statements: Fix parameter number gaps in normalized queries

On 2025-May-22, Dmitry Dolgov wrote:

> Just to call this out, I don't think there is an agreement on squashing
> Params, which you have added into 0002.

Actually I think we do have agreement on squashing PARAM_EXTERN Params.
https://postgr.es/m/3086744.1746500983@sss.pgh.pa.us

> Now, both flavour of the proposed solution could be still concidered too
> invasive to be applied as a bug fix. I personally don't see it like
> this, but I'm obviously biased. This leads us to following decisions to
> be made:
> 
> * Is modifying parser (either adding a new node or modifying an existing
>   one) acceptable at this stage? I guess it would be enough to collect
>   couple of votes yes/no in this thread.

IMO adding a struct as suggested is okay, especially if it reduces the
overall code complexity.  But we don't want a node, just a bare struct.
Adding a node would be more troublesome.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"Pido que me den el Nobel por razones humanitarias" (Nicanor Parra)