Re: Funny representation in pg_stat_statements.query.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Funny representation in pg_stat_statements.query.
Дата
Msg-id 317.1390332378@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Funny representation in pg_stat_statements.query.  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Ответы Re: Funny representation in pg_stat_statements.query.  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Список pgsql-hackers
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Performance Improvement by reducing WAL for Update Operation
Следующее
От: Vik Fearing
Дата:
Сообщение: Re: Closing commitfest 2013-11