Re: queryId constant squashing does not support prepared statements

From: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
To: Sami Imseih <samimseih(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, 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-21 15:00:06
Message-ID: rfgr5womss3ze644zeul3wvee2xeitdr56bse6fprumfqiyscu@a23kcsqjiscp
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2025-05-21 15:34:43 MERGE issues around inheritance
Previous Message Peter Eisentraut 2025-05-21 14:58:09 Re: Add comment explaining why queryid is int64 in pg_stat_statements