Re: Funny representation in pg_stat_statements.query.

Hello,

> >> Since this becomes more than a simple bug fix, I think it is too
> >> late for 9.4 now. I'll work on this in the longer term.
>
> OK. I will get around to it someday, but if you do it first, that's fine.

Nevertheless of my words, the drive is getting diminished after
the issue was settled:-p Anyway I'll keep this in my mind.

> > The fundamental cause of this issue is Const node which conveys
> > the location of other than constant tokens. Any other nodes, for
> > instance TypeCasts, are safe.
>
> > So this is fixed by quite simple way like following getting rid
> > of the referred difficulties of keeping the code sane and total
> > loss of token locations. (white spaces are collapsed for readability)
>
> Huh, that's a cute idea. It's certainly a kluge with a capital K,
> and might fail to extend to new cases; but if we're intending to
> replace all these cases with new special-purpose parse nodes soon,
> neither of those objections seem very strong.

Yes, but reforming parser so as to use special-purpose nodes
impacts largely so this measure was brought up for the offhand.

> The main concern I'd have would be whether there could be any weird
> change in error cursor locations, but right offhand that's probably
> not a problem. We know in each of these cases that there will be
> some node produced by the coercion step, so the location won't
> disappear entirely, and so exprLocation() of the node tree as a
> whole should be the same. Not labeling the A_Const could result in
> failure to produce an error location for a complaint about invalid
> input for the coercion --- but surely that should never happen in
> any of these cases.

Surely.

> So right offhand I think this is probably workable, and while it's
> ugly it's an appropriate amount of effort to put into code whose
> days are numbered anyhow.

Thank you.

reagrds,

--
Kyotaro Horiguchi
NTT Open Source Software Center