| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
| 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 19:06:04 |
| Message-ID: | 7688.1484334364@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Fabien COELHO <coelho(at)cri(dot)ensmp(dot)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
| Attachment | Content-Type | Size |
|---|---|---|
| stmt-list-rewrite-2.patch.gz | application/x-gzip | 38.6 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2017-01-13 19:07:02 | pgsql: Fix a bug in how we generate partition constraints. |
| Previous Message | Robert Haas | 2017-01-13 18:38:00 | Re: plan_rows confusion with parallel queries |