Re: [HACKERS] BUG: pg_stat_statements query normalization issues with combined queries - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] BUG: pg_stat_statements query normalization issues with combined queries
Date
Msg-id 26942.1482862983@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] BUG: pg_stat_statements query normalization issueswith combined queries  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: [HACKERS] BUG: pg_stat_statements query normalization issueswith combined queries  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
Fabien COELHO <coelho@cri.ensmp.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



pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: [HACKERS] Hooks
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Hooks