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

Noah Misch <noah@leadboat.com>

From: Noah Misch <noah@leadboat.com>

To: Peter Eisentraut <peter_e@gmx.net>

Cc: Peter Geoghegan <peter@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, Andrew Dunstan <andrew@dunslane.net>, PG Hackers <pgsql-hackers@postgresql.org>

Date: 2012-03-20T04:29: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 →

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 Mon, Mar 19, 2012 at 09:49:32PM +0200, Peter Eisentraut wrote:
> On m??n, 2012-03-19 at 02:35 +0000, Peter Geoghegan wrote:
> > I see your point of view. I suppose I can privately hold onto the test
> > suite, since it might prove useful again.
> 
> I would still like to have those tests checked in, but not run by
> default, in case someone wants to hack on this particular feature again.

Agreed.  Also, patch review becomes materially smoother when the author
includes comprehensive tests.  When a usage I wish to verify already appears
in the submitted tests, that saves time.  I respect the desire to keep regular
"make check" lean, but not if it means comprehensive tests get written to be
buried in the mailing list archives or never submitted at all.