Horton

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

Peter Geoghegan <peter@2ndquadrant.com>

View thread
From: Peter Geoghegan <peter@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Daniel Farina <daniel@heroku.com>, Robert Haas <robertmhaas@gmail.com>, PG Hackers <pgsql-hackers@postgresql.org>
Date: 2012-03-27T18:47:06Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.

  2. Extend the parser location infrastructure to include a location field in

  3. Teach eval_const_expressions() to simplify an ArrayCoerceExpr to a constant

Attachments

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