Horton

Re: queryId constant squashing does not support prepared statements

Sami Imseih <samimseih@gmail.com>

View thread
From: Sami Imseih <samimseih@gmail.com>
To: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Junwang Zhao <zhjwpku@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-05-22T01:22:19Z
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

Attachments

> > > 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.

Looking at the VALUES expression case, we will need to carry the info
with SelectStmt and ultimately to RangeTblEntry which is where the
values_list is, so either approach we take RangeTblEntry will need the
LocationExpr pointer or the additional ParseLoc info I am suggesting.
A_Expr is not used in the values list case.


> I'll take a look at the proposed change, but a bit later.

Here is a v4 to compare with v3.

0001- is the infrastructure to track the boundaries
0002- the changes to jumbling
0003 - the additional tests introduced in v3


--
Sami