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