Stephen Frost <sfrost@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
