Horton

Re: queryId constant squashing does not support prepared statements

Dmitry Dolgov <9erthalion6@gmail.com>

View thread
From: Dmitry Dolgov <9erthalion6@gmail.com>
To: Sami Imseih <samimseih@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Junwang Zhao <zhjwpku@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-05-21T15:00:06Z
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 Tue, May 20, 2025 at 04:50:12PM GMT, Sami Imseih wrote:
> > At the same time AFAICT there isn't much more code paths
> > to worry about in case of a LocationExpr as a node
>
> I can imagine there are others like value expressions,
> row expressions, json array expressions, etc. that we may
> want to also normalize.

Exactly. When using a node, one can explicitly wrap whatever is needed
into it, while otherwise one would need to find a new way to piggy back
on A_Expr in a new context.

> There are other examples of fields that are minimally used in other structs.
> Here is one I randomly spotted in SelectStmt such as SortClause, Limit options,
> etc.

The way I see it, there is a difference -- I assume those structures
were designed for such cases, where the location range would be just
slapped on top of A_Expr.

> Attached is a sketch of what I mean. There is a private struct that tracks
> the list boundaries and this can wrap in_expr or whatever else makes
> sense in the future.

Just fyi, I don't think this thread is attached to any CF item, meaning
it will not be pulled by the CF bot. In that case feel free to post
diffs in the patch format. I'll take a look at the proposed change, but
a bit later.