Re: [HACKERS] Funny representation in pg_stat_statements.query.

2014-01-22 Thread Alvaro Herrera
Kyotaro HORIGUCHI wrote: 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

Re: [HACKERS] Funny representation in pg_stat_statements.query.

2014-01-21 Thread Kyotaro HORIGUCHI
Hello, I found it would be reasonably fixed by small modifications. - 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

Re: [HACKERS] Funny representation in pg_stat_statements.query.

2014-01-21 Thread Tom Lane
Kyotaro HORIGUCHI horiguchi.kyot...@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.

Re: [HACKERS] Funny representation in pg_stat_statements.query.

2014-01-21 Thread Peter Geoghegan
On Tue, Jan 21, 2014 at 12:30 AM, Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp wrote: 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

Re: [HACKERS] Funny representation in pg_stat_statements.query.

2014-01-21 Thread Tom Lane
Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp writes: 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

Re: [HACKERS] Funny representation in pg_stat_statements.query.

2014-01-21 Thread Kyotaro HORIGUCHI
Hi, considering on pg_stat_statements itself, pg There was a more obvious case of this that I noticed during the pg development of pg_stat_statements query normalization. As you may have pg noticed, that was addressed by this commit: pg pg

Re: [HACKERS] Funny representation in pg_stat_statements.query.

2014-01-21 Thread Kyotaro HORIGUCHI
Hello, tgl So this is fixed by quite simple way like following getting rid tgl of the referred difficulties of keeping the code sane and total tgl loss of token locations. (white spaces are collapsed for readability) tgl tgl Committed with minor adjustments (improved comments, and hit one tgl

Re: [HACKERS] Funny representation in pg_stat_statements.query.

2014-01-21 Thread Peter Geoghegan
On Tue, Jan 21, 2014 at 7:29 PM, Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp wrote: This apparently seems that the query passing through pg_stat_statements twice during single execution. Actually, the first one is a by-product of planning (simplify_function) and the second is just what

Re: [HACKERS] Funny representation in pg_stat_statements.query.

2014-01-21 Thread Kyotaro HORIGUCHI
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

Re: [HACKERS] Funny representation in pg_stat_statements.query.

2014-01-19 Thread Kyotaro HORIGUCHI
Thank you. tgl Hello, I noticed that pg_stat_statements.query can have funny values. tgl tgl I don't think that's an acceptable reason for lobotomizing the parser's tgl ability to print error cursors, which is what your first patch does tgl (and without even any documentation that would keep

[HACKERS] Funny representation in pg_stat_statements.query.

2014-01-17 Thread Kyotaro HORIGUCHI
Hello, I noticed that pg_stat_statements.query can have funny values. | =# select pg_stat_statements_reset(); | =# select current_timestamp(0); | snip | =# select query from pg_stat_statements; |query | | select ?(0); | select

Re: [HACKERS] Funny representation in pg_stat_statements.query.

2014-01-17 Thread Tom Lane
Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp writes: Hello, I noticed that pg_stat_statements.query can have funny values. I don't think that's an acceptable reason for lobotomizing the parser's ability to print error cursors, which is what your first patch does (and without even any