Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation) - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)
Date
Msg-id CAEYLb_XjHontuTdkgkbMC+E55PXkT4-Oi1yf_rdSeuF1SHsi2Q@mail.gmail.com
Whole thread Raw
In response to Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 27 March 2012 18:15, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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).

It seems reasonable to suggest that this will provide everything 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.

It has been suggested to me before that comparisons with function
pointers - using them as a flag, in effect - is generally iffy, but
that particular usage seems reasonable to me.

Attached is a revision with the suggested changes.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Cross-backend signals and administration (Was: Re: pg_terminate_backend for same-role)
Next
From: Robert Haas
Date:
Subject: Re: Patch: add timing of buffer I/O requests