Re: queryId constant squashing does not support prepared statements

From: Junwang Zhao <zhjwpku(at)gmail(dot)com>
To: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Sami Imseih <samimseih(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-09 03:05:43
Message-ID: CAEG8a3KuG-thQ0o=Qg-X5Cs==mYmk9L5K5-xBWE1B3eqy5bptA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Dmitry,

On Fri, May 9, 2025 at 3:36 AM Dmitry Dolgov <9erthalion6(at)gmail(dot)com> wrote:
>
> > On Thu, May 08, 2025 at 02:22:00PM GMT, Michael Paquier wrote:
> > 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().
>
> To clarify, I had in mind something like in the attached patch. The
> idea is to make start/end location capturing relatively independent from
> the constants squashing. The new parsing node conveys the location
> information, which is then getting transformed to be a part of an
> ArrayExpr. It's done for in_expr only here, something similar would be
> needed for array_expr as well. Feedback is appreciated.

+/*
+ * A wrapper expression to record start and end location
+ */
+typedef struct LocationExpr
+{
+ NodeTag type;
+
+ /* the node to be wrapped */
+ Node *expr;
+ /* token location, or -1 if unknown */
+ ParseLoc start_location;
+ /* token location, or -1 if unknown */
+ ParseLoc end_location;
+} LocationExpr;

Why not a location and a length, it should be more natural, it
seems we use this convention in some existing nodes, like
RawStmt, InsertStmt etc.

--
Regards
Junwang Zhao

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2025-05-09 05:08:26 Re: Issues with 2PC at recovery: CLOG lookups and GlobalTransactionData
Previous Message Richard Guo 2025-05-09 03:05:07 Re: PG 18 release notes draft committed