From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | robertmhaas(at)gmail(dot)com, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: BUG: pg_stat_statements query normalization issues with combined queries |
Date: | 2016-12-22 07:39:52 |
Message-ID: | alpine.DEB.2.20.1612220830070.3892@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Kyotaro-san,
> [...] Agreed that copying statement string would be too much. But the
> new *Stmt node should somehow have also the end location of the
> statement since the user of a parse tree cannot look into another one.
Yes. I was thinking of adding a "length" field next to "location", where
appropriate.
>> So I'm rather still in favor of my initial proposal, that is extend
>> the existing location information to statements, not only some tokens.
>
> I thought that it's too much to let all types of parse node have
> location but grepping the gram.y with "makeNode" pursuaded me to
> agree with you.
Indeed...
> After changing all *Stmt nodes, only several types of nodes seems
> missing it.
Yes. I'll try to put together a patch and submit it to the next CF.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | tushar | 2016-12-22 08:05:37 | Re: Parallel Index Scans |
Previous Message | Michael Meskes | 2016-12-22 07:37:18 | Re: [bug fix] Trivial ecpg bug which can cause memory overrun |