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

Peter Geoghegan <peter(at)2ndquadrant(dot)com> writes:
> Is there anything that I could be doing to help bring this patch
> closer to a committable state?

Sorry, I've not actually looked at that patch yet. I felt I should
push on Andres' CTAS patch first, since that's blocking progress on
the command triggers patch.

> I'm thinking of the tests in particular
> - do you suppose it's acceptable to commit them more or less as-is?

If they rely on having python, that's a 100% guaranteed rejection
in my opinion. It's difficult enough to sell people on incremental
additions of perl dependencies to the build/test process. Bringing
in an entire new scripting language seems like a nonstarter.

I suppose we could commit such a thing as an appendage that doesn't
get run in standard builds, but then I see little point in it at all.
Tests that don't get run regularly are next door to useless.

Is there a really strong reason why adequate regression testing isn't
possible in a plain-vanilla pg_regress script? A quick look at the
script says that it's just doing some SQL commands and then checking the
results of queries on the pg_stat_statements views. Admittedly the
output would be bulkier in pg_regress, which would mean that we'd not
likely want several hundred test cases. But IMO the objective of a
regression test is not to memorialize every single case the code author
thought about during development. ISTM it would not take very many
cases to have reasonable code coverage.

regards, tom lane