Horton

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

Simon Riggs <simon@2ndquadrant.com>

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

On Fri, Mar 2, 2012 at 5:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

Hmm, not deaf you know. I would never push through a patch that isn't
ready for commit. If I back something it is because it is ready for
use in production by PostgreSQL users, in my opinion. I get burned
just as much, if not more, than others if that's a bad decision, so
its not given lightly.

-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services