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>

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-28T14:45:25Z

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 →

Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.
- 9dbf2b7d75de 9.2.0 cited
Extend the parser location infrastructure to include a location field in
- a2794623d292 8.4.0 cited
Teach eval_const_expressions() to simplify an ArrayCoerceExpr to a constant
- 6734182c169a 8.4.0 cited

On 28 March 2012 15:25, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> That's been an issue right along for cases such as EXPLAIN and EXECUTE,
> I believe.

Possible, since I didn't have test coverage for either of those 2 commands.

 Perhaps the right thing is to consider such executor calls
> as nested statements --- that is, the ProcessUtility hook ought to
> bump the nesting depth too.

That makes a lot of sense, but it might spoil things for the
pg_stat_statements.track = 'top' + pg_stat_statements.track_utility =
'on' case. At the very least, it's a POLA violation, to the extent
that if you were going to do this, you might mandate that nested
statements be tracked along with utility statements (probably while
defaulting to having both off, which would be a change).

Since you've already removed the intoClause chunk, I'm not sure how
far underway the review effort is - would you like me to produce a new
revision, or is that unnecessary?

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