Re: queryId constant squashing does not support prepared statements

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