Horton

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>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Josh Berkus <josh@agliodbs.com>
Cc: Peter Geoghegan <peter@2ndquadrant.com>, pgsql-hackers@postgresql.org
Date: 2012-03-02T17:48:30Z
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

Josh Berkus <josh@agliodbs.com> writes:
>> It would probably be prudent to concentrate on getting the core
>> infrastructure committed first. That way, we at least know that if
>> this doesn't get into 9.2, we can work on getting it into 9.3 knowing
>> that once committed, people won't have to wait over a year at the very

> I don't see why we can't commit the whole thing.  This is way more ready
> for prime-time than checksums.

We'll get to it in due time.  In case you haven't noticed, there's a lot
of stuff in this commitfest.  And I don't follow the logic that says
that because Simon is trying to push through a not-ready-for-commit
patch we should drop our standards for other patches.

			regards, tom lane