Peter Geoghegan <pe...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers