Julien Rouhaud <rjuju...@gmail.com> writes: > On Sun, Jun 27, 2021 at 11:31:53AM +0800, Julien Rouhaud wrote: >> On Sat, Mar 11, 2017 at 11:09:32PM +0100, Julien Rouhaud wrote: >>> When a query contains parameters, the original param node contains the token >>> location. However, this information is lost when the Const node is >>> generated, >>> this one will only contain position -1 (unknown). >>> >>> FWIW, we do have a use case for this (custom extension that tracks quals >>> statistics, which among other thing is used to regenerate query string from >>> a >>> pgss normalized query, thus needing the original param location).
I looked at this for a bit. It's certainly a simple and harmless-looking patch, but I'm having a hard time buying that it's actually useful in isolation. In particular, even if we keep the Param's location in the immediately-resulting Const, what happens when that node is further mashed by planner transformations? As an example, given regression=# prepare foo(int) as select $1 + 1; PREPARE regression=# explain verbose execute foo(42); QUERY PLAN ------------------------------------------ Result (cost=0.00..0.01 rows=1 width=4) Output: 43 (2 rows) this patch isn't gonna do anything to help you figure out where the 42 went. I thought for a bit about also having evaluate_expr() inject the exprLocation(expr) into its result Const, but in this example that would likely result in having the 43 labeled with the offset of the $1 (given exprLocation's penchant for preferring the leftmost token location). That could be more confusing not less, especially when you consider that the variant case "1 + $1" would not be traceable to the Param at all. I also fear that this is still just the tip of the iceberg, in terms of when rewriting and planning preserve useful info about the source location of modified Nodes. There's probably other places to touch if we want to have consistent results. So I'm not really convinced that there's a fully-baked use case here, and would like more detail about how you hope to use the location value. regards, tom lane