Re: BUG: pg_stat_statements query normalization issues with combined queries

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Craig Ringer <craig(dot)ringer(at)2ndquadrant(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: BUG: pg_stat_statements query normalization issues with combined queries
Date: 2017-01-13 22:22:57
Message-ID: alpine.DEB.2.20.1701132259260.15294@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> Here's a v2 that does it like that.

Applies, compiles, overall & pgss make check are both ok.

Personnally I find having RawStmt only for the top parsed statement
cleaner, and it significantly reduces changes in the parser, as expected,
without inducing too much changes elsewhere.

Same comment as on v1: I'm wondering about the actual coverage of the
default tests... I cannot say I understand everything.

> It ends up being about 30 fewer lines of code overall, despite there
> being four places that have to make ad-hoc RawStmt nodes. On the whole
> I feel like this is cleaner,

I agree: Better typing, more homogeneous code (PlannedStmt for all),
less ad-hoc checks to work around utility statements...

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-01-13 22:39:04 Re: Protect syscache from bloating with negative cache entries
Previous Message Alvaro Herrera 2017-01-13 22:08:30 Re: GSoC 2017