Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Josh Berkus <josh@agliodbs.com>, Peter Geoghegan <peter@2ndquadrant.com>, pgsql-hackers@postgresql.org
Date: 2012-03-03T00:01:24Z
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 Fri, Mar 2, 2012 at 4:56 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > Checksums patch isn't sucking much attention at all but admittedly > there are some people opposed to the patch that want to draw out the > conversation until the patch is rejected, Wow. Sounds like a really shitty thing for those people to do - torpedoing a perfectly good patch for no reason. I have an alternative theory, though: they have sincere objections and don't accept your reasons for discounting those objections. > I'm not sure how this topic is even raised here, since the patches are > wholly and completely separate, apart from the minor and irrelevant > point that the patch authors both work for 2ndQuadrant. If that > matters at all, I'll be asking how and why. It came up because Josh pointed out that this patch is, in his opinion, in better shape than the checksum patch. I don't believe anyone's employment situation comes into it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company