> On Tue, May 06, 2025 at 03:01:32PM GMT, Sami Imseih wrote:
> > > Without properly accounting for the boundaries of the list of
> > > expressions, i.e.,
> > > the start and end positions of '(' and ')' or '[' and ']' and normalizing
> > > the
> > > expressions in between, it will be very difficult for the normalization to
> > > behave sanely.
> >
> > I don't think having the end location in this case would help -- when it
> > comes to ParseFuncOrColumn, looks like for coerce functions it just
> > replaces the original FuncCall with the argument expression. Meaning
> > that when jumbling we have only the coerce argument expression (Const),
> > which ends before the closing brace, not the parent expression.
>
> If we are picking up the start and end points from gram.c and we add these
> positions to A_Expr or A_ArrayExpr and then make them available to ArrayExpr,
> then we know the exact boundary of the IN list. Even if a function
> call is simplified down
> to a constant, it will not really matter because we are going to normalize
> between the original opening and closing parentheses of the IN list.
> What do you think?
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.
