Stephen Frost <sfr...@snowman.net> writes: > I believe that what Peter was getting at is that the pg_dump TAP tests > create a whole slew of objects in just a few seconds and are able to > then exercise those code-paths in pg_dump, without needing to run the > entire serial regression test run.
Right. But there's a certain amount of serendipity involved in using the core regression tests' final results. For example, I don't know how long it would've taken us to understand the problems around dumping and reloading child tables with inconsistent column orders, had there not been examples of that in the regression tests. I worry that creating a sterile set of objects for testing pg_dump will leave blind spots, because it will mean that we only test cases that we explicitly created test cases for. > I'm still not completely convinced that we actually need to > independently test pg_upgrade by creating all the objects which the > pg_dump TAP tests do, given that pg_upgrade just runs pg_dump > underneath. If we really want to do that, however, what we should do is > abstract out the pg_dump set of tests into a place that both the pg_dump > and pg_upgrade TAP tests could use them to create all the types of > objects which are supported to perform their tests. I think it's largely pointless to test pg_dump --binary-upgrade except as a part of pg_upgrade. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers