Re: [HACKERS] BUG: pg_stat_statements query normalization issueswith combined queries

> One thing that I'm not quite satisfied with is the business with
> non-top-level RawStmt nodes in some utility statements. 
> a wart from gram.y's perspective, and it's mostly a wart from analyze.c's
> perspective as well --- the parse analyze routines mostly just throw away
> the non-top-level RawStmt.
>
> The original reason for doing it was that DoCopy needs to call
> pg_analyze_and_rewrite() on the sub-statement, and I wanted
> pg_analyze_and_rewrite's argument to be declared as RawStmt,

My 0,02€, feel free to ignore them:

Personnaly when I had started doing a version I had decided to only change 
the type at top level, and then I made a few functions being resilient 
about having a RawStmt (that I had called ParsedStmt in my version) or
a direct statement, rather than change the type, I had kept Node*.

Now I see the benefit of changing the type, because the compiler will say 
if there is an issue, and their is no hidden level changes.

> 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.

-- 
Fabien.