Hello Tom,
> [...] It's touching every single utility statement type, which is not
> only pretty invasive in itself, but will break any pending patches that
> add more utility statement types.
Yep, but it is limited to headers and the break is trivial...
> And you've not followed through on the implications of adding those
> fields in, for instance, src/backend/nodes/;
Hmmm, probably you are pointing out structure read/write functions.
I would have hoped that such code would be automatically derived from the
corresponding struct definition...
>> I understand that you suggest to add a new intermediate structure [...]
>> So that raw_parser would return a List<ParseNode> instead of a
>> List<Node>, and the statements would be unmodified.
>
> Yeah, that's what I was thinking of. There aren't very many places that
> would need to know about that, I believe; [...]
Hmmm. I've run into a tiny small ever so little detail in trying to apply
this clever approach...
For fixing the information in pg_stat_statement, the location data must be
transported from the parsed node to the query to the planned node, because
the later two nodes types are passed to different hooks.
Now the detail is that utility statements, which seems to be nearly all of
them but select/update/delete/insert, do not have plans: The statement
itself is its own plan... so there is no place to store the location &
length.
As adding such fields to store the information in the structures is no go
area, I'm hesitating about the course to follow to provide a solution
acceptable to you.
Would you have any other clever proposition or advice about how to
proceed?
I thought of creating yet another node "utility plans with locations" or
maybe reuse the "parsed node" for the purpose, but then it has to be
managed in quite a few places as well.
For the parser output, there is 4 raw_parser calls but also 10
pg_parse_query calls to manage. I'm not sure that going this way will fit
the "few lines of code" bill...
--
Fabien.