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

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 s

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 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 expected by users. It surely

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

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> http://git.postgresql.org/gitweb/?p=postgresql.git;

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

2014-01-21 Thread Tom Lane
Kyotaro HORIGUCHI 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 referred difficulties of keepin

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 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 following getting rid > of t

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

2014-01-21 Thread Tom Lane
Kyotaro HORIGUCHI writes: >> - CURRENT_TIME and the like are parsed into the nodes directly >> represents the node specs in gram.y >> >> 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 someda

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

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 ke

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

2014-01-17 Thread Tom Lane
Kyotaro HORIGUCHI 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 documentation that would keep someone