Re: queryId constant squashing does not support prepared statements

> > On Fri, May 09, 2025 at 12:47:19PM GMT, Sami Imseih wrote:
> > So, I think we can create a new parse node ( parsenode.h ) that will only be
> > used in parsing (and gram.c only ) to track the start/end locations
> > and List and
> > based on this node we can create A_ArrayExpr and A_Expr with the List
> > of boundaries,
> > and then all we have to do is update ArrayExpr with the boundaries during
> > the respective transformXExpr call. This seems like a much simpler approach
> > that also addresses Michael's concern of defining static variables in gram.y to
> > track the boundaries.
>
> The static variables was only part of the concern, another part was
> using A_Expr to carry this information, which will have impact on lots
> of unrelated code.

What would be the problem if A_Expr carries an extra pointer to a List?
It already had other fields, rexpr, lexpr and location that could be no-op.

Also, LocationExpr is not really an expression node, but a wrapper to
an expression node, so I think it's wrong to define it as a Node and be
required to add the necessary handling for it in nodeFuncs.c. I think we
can just define it as a struct in gram.y so it can carry the locations of the
expression and then set the List of the location boundaries in
A_Expr and A_ArrayExpr. right?

typedef struct LocationExpr
{
Node *expr;
ParseLoc start_location;
ParseLoc end_location;
} LocationExpr;

--
Sami