Simon Riggs <si...@2ndquadrant.com> writes: > On 16 October 2015 at 20:17, Robert Haas <robertmh...@gmail.com> wrote: >>>> - DDL deparsing testing module should have detected that transforms >>>> were not supported, but it failed to notice that. There's no thread >>>> linked to this one either, but the description of the issue seems >>>> clear enough. Alvaro, any chance that you can, as the comment says, >>>> whack it until it does?
>>> I've been looking at this on and off, without anything useful to share >>> yet. One approach that was suggested (which I don't like much, but I >>> admit is a possible approach) is that we just need to remain vigilant >>> that all features that add DDL properly test the event trigger side of >>> it, just as we remain vigilant about pg_dump support without having any >>> explicit test that it works. >> I really, really hope that's not where we end up. Just shoot me now. > I share your pain, but the latter appears to be the only actionable > proposal at present. I had the idea that the test suite would consist of "run the standard regression tests with a DDL deparsing hook installed, and see if it fails anywhere". This would not prove that the deparsing logic is right, certainly, but it would at least catch errors of omission for any DDL tested in the regression tests, which we could hope is pretty much everything. > Why do we need to fix DDL when pg_dump remains annoying in the same way? It is not true that we have no test coverage for pg_dump: the pg_upgrade test exercises pg_dump too. The difficulty with pg_dump is that this approach only tests dumping of objects that are left behind at the end of the regression tests, and we get too many submissions from neatniks who think that test cases ought to delete all the objects they create. But that is just a matter of needing to formulate test cases with this in mind. > Why do we need to fix it now? Surely this will break things in later > releases, but not in 9.5, since we aren't ever going to add DDL to 9.5 > again. This is a fair point. We still need a test methodology here, but it's not clear why it needs to be regarded as a 9.5 blocker. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers