Julien Rouhaud <rjuju123@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
