Re: BUG: pg_stat_statements query normalization issues with combined queries
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Fabien COELHO <coelho@cri.ensmp.fr>
Cc: Craig Ringer <craig.ringer@2ndquadrant.com>,
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>,
Robert Haas <robertmhaas@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2017-01-13T19:06:04Z
Lists: pgsql-hackers
Attachments
- stmt-list-rewrite-2.patch.gz (application/x-gzip) patch
- (unnamed) (text/plain)
Fabien COELHO <coelho@cri.ensmp.fr> writes: >> One thing that I'm not quite satisfied with is the business with >> non-top-level RawStmt nodes in some utility statements. >> ... >> So I'm now thinking that it might be better if the grammar produced >> RawStmt only at top level, and anybody who calls pg_analyze_and_rewrite >> on sub-sections of a utility statement has to cons up a RawStmt to put >> at the top of the sub-query. > Why not. The lazy programmer I am notices that there seems to be 6 > instances, this is not too bad, some of which are already dealt with. The > RawStmt may not need to be allocated dynamically, a stack instance could > be enough. Here's a v2 that does it like that. 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, although there's room to argue that. Still, the extra cruft is in places that I'm suspicious are wrong anyway, as I noted. regards, tom lane
Commits
-
Teach contrib/pg_stat_statements to handle multi-statement commands better.
- 83f2061dd037 10.0 landed
-
Change representation of statement lists, and add statement location info.
- ab1f0c822571 10.0 landed
-
Revert my bad decision of about a year ago to make PortalDefineQuery
- 1591fcbec77f 8.4.0 cited