On Wed, Jul 14, 2021 at 02:02:18PM -0400, Tom Lane wrote:
>
> Hm. I guess this point (i.e. that the Param substitution should result
> in the identical plan tree as writing a literal constant would have)
> has some force. I still feel like your application is pretty shaky,
> but I don't really h
Julien Rouhaud writes:
> On Tue, Jul 13, 2021 at 07:01:24PM -0400, Tom Lane wrote:
>> 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.
> As I said I have no doubt that there are other cases which a
On Tue, Jul 13, 2021 at 07:01:24PM -0400, Tom Lane wrote:
>
> 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 pencha
Julien Rouhaud 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 Con
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
> > genera
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
