Horton

Re: queryId constant squashing does not support prepared statements

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: Sami Imseih <samimseih@gmail.com>, Junwang Zhao <zhjwpku@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-05-08T05:22:00Z
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 Wed, May 07, 2025 at 10:41:22AM +0200, Dmitry Dolgov wrote:
> Ah, I see what you mean. I think the idea is fine, it will simplify
> certain things as well as address the issue. But I'm afraid adding
> start/end location to A_Expr is a bit too invasive, as it's being used
> for many other purposes. How about introducing a new expression for this
> purposes, and use it only in in_expr/array_expr, and wrap the
> corresponding expressions into it? This way the change could be applied
> in a more targeted fashion.

Yes, that feels invasive.  The use of two static variables to track
the start and the end positions in an expression list can also be a
bit unstable to rely on, I think.  It seems to me that this part
could be handled in a new Node that takes care of tracking the two
positions, instead, be it a start/end couple or a location/length
couple?  That seems necessary to have when going through
jumbleElements().
--
Michael