stored procedures vs pg_stat_statements

Hello,

I've noticed that in pg_stat_statements, stored procedures are almost
always given a unique query id unless the query is textually identical.
pg_stat_statements.c makes this pretty clear as procedures are considered
utility statements and no normalization analysis is done against them.
Client side invoked statements appear to be able to be parameterized so
that they might be normalized correctly, but AFAICT there is no way to do
this from the server or any non-parameterizing client (say, dblink).

Suffice it to say, pg_stat_statements is an administrator's dream and
heavily procedure wrapped databases might struggle to generate useful
statistics leading to lack of insight.

From pg_stat_statements.c in ProcessUtility():

/*
* Force utility statements to get queryId zero. We do this even
in cases
* where the statement contains an optimizable statement for which a
* queryId could be derived (such as EXPLAIN or DECLARE CURSOR).
For such
* cases, runtime control will first go through ProcessUtility and
then
* the executor, and we don't want the executor hooks to do
anything,
* since we are already measuring the statement's costs at the
utility
* level.
*
* Note that this is only done if pg_stat_statements is enabled and
* configured to track utility statements, in the unlikely
possibility
* that user configured another extension to handle utility
statements
* only.
*/
Can this simply be disabled for stored procedures as a special case? I'm
hoping this might do something useful that is also safe. Curious if anyone
has any thoughts on this.

merlin