Peter Geoghegan <pe...@2ndquadrant.com> writes:
>> On 22 March 2012 17:19, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> Either way, I think we'd be a lot better advised to define a single
>>> hook "post_parse_analysis_hook" and make the core code responsible
>>> for calling it at the appropriate places, rather than supposing that
>>> the contrib module knows exactly which core functions ought to be
>>> the places to do it.
> I have done this too.
The "canonicalize" argument to the proposed hook seems like a bit of a
crock. You've got the core code magically setting that in a way that
responds to extremely pg_stat_statements-specific concerns, and I am not
very sure it's right even for those concerns.
I am thinking that perhaps a reasonable signature for the hook function
would be
void post_parse_analyze (ParseState *pstate, Query *query);
with the expectation that it could dig whatever it wants to know out
of the ParseState (in particular the sourceText is available there,
and in general this should provide everything that's known at parse
time).
Now, if what it wants to know about is the parameterization status
of the query, things aren't ideal because most of the info is hidden
in parse-callback fields that aren't of globally exposed types. However
we could at least duplicate the behavior you have here, because you're
only passing canonicalize = true in cases where no parse callback will
be registered at all, so pg_stat_statements could equivalently test for
pstate->p_paramref_hook == NULL.
Thoughts, other ideas?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
