Re: BUG: pg_stat_statements query normalization issues with combined queries

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, craig(dot)ringer(at)2ndquadrant(dot)com, 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-27 18:23:03
Message-ID: 26942.1482862983@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> writes:
> How? The issue is that stmtmulti silently skip some ';' when empty
> statements are found, so I need to keep track of that to know where to
> stop, using the beginning location of the next statement, which is
> probably your idea, does not work.

Maybe you should undo that. I've generally found that trying to put
optimizations into the grammar is a bad idea; it's better to KISS in
gram.y and apply optimizations later on.

>> - Make all parse nodes have the following two members at the
>> beginning. This unifies all parse node from the view of setting
>> their location. Commenting about this would be better.
>>
>> | NodeTag type;
>> | int location;

I do not like this. You are making what should be a small patch into
a giant, invasive one. I'd think about adding a single parse node type
that corresponds to "stmt" in the grammar and really doesn't do anything
but carry the location info for the overall statement. That info could
then be transferred into the resulting Query node. Problem solved with
(I think) very little code touched.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-12-27 18:32:46 Re: Hooks
Previous Message David Fetter 2016-12-27 18:16:28 Hooks