Peter Eisentraut <peter@eisentraut.org> writes:
> The problem is, we don't really have any end-to-end coverage of
> dump
> restore
> dump again
> compare the two dumps
> with a database with lots of interesting objects in it.
I'm very much against adding another full run of the core regression
tests to support this. But beyond the problem of not bloating the
check-world test runtime, there is the question of what this would
actually buy us. I doubt that it is worth very much, because
it would not detect bugs-of-omission in pg_dump. As I remarked in
the other thread, if pg_dump is blind to the existence of some
feature or field, testing that the dumps compare equal will fail
to reveal that it didn't restore that property.
I'm not sure what we could do about that. One could imagine writing
some test infrastructure that dumps out the contents of the system
catalogs directly, and comparing that instead of pg_dump output.
But that'd be a lot of infrastructure to write and maintain ...
and it's not real clear why it wouldn't *also* suffer from
I-forgot-to-add-this hazards.
On balance, I think there are good reasons that we've not added
such a test, and I don't believe those tradeoffs have changed.
regards, tom lane
