Re: Funny representation in pg_stat_statements.query.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Funny representation in pg_stat_statements.query.
Date: 2014-01-21 19:26:18
Message-ID: 317.1390332378@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> writes:
>> - CURRENT_TIME and the like are parsed into the nodes directly
>> represents the node specs in gram.y
>> <blah, blah>
>> 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.

> 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.

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.

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Vik Fearing 2014-01-21 19:38:29 Re: Closing commitfest 2013-11
Previous Message Robert Haas 2014-01-21 19:11:36 Re: Performance Improvement by reducing WAL for Update Operation