Re: queryId constant squashing does not support prepared statements
От | Dmitry Dolgov |
---|---|
Тема | Re: queryId constant squashing does not support prepared statements |
Дата | |
Msg-id | 77y64s2buf6o7eq7xqsdppzno42t7h3b5vvzpe6wu3v6amicie@6tnzsz7hzviv обсуждение исходный текст |
Ответ на | Re: queryId constant squashing does not support prepared statements (Sami Imseih <samimseih@gmail.com>) |
Список | pgsql-hackers |
> 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.
В списке pgsql-hackers по дате отправления: