Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)

From: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Daniel Farina <daniel(at)heroku(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)
Date: 2012-03-27 18:47:06
Message-ID: CAEYLb_XjHontuTdkgkbMC+E55PXkT4-Oi1yf_rdSeuF1SHsi2Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 27 March 2012 18:15, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 Content-Type Size
pg_stat_statements_norm_2012_03_27.patch text/x-patch 63.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-03-27 18:58:39 Re: Patch: add timing of buffer I/O requests
Previous Message Andres Freund 2012-03-27 18:21:22 Re: Cross-backend signals and administration (Was: Re: pg_terminate_backend for same-role)