Andres Freund wrote: > Isn't a full test with a separate initdb, create extension etc. a really > heavyhanded way to test this? I mean that's a test where the setup takes > up to 10s, whereas the actual runtime is in the millisecond range?
I spent some time looking over this patch yesterday, and that was one concern I had too. I was thinking that if we turn this into a single module that can contain several extensions, or several pg_dump-related tests, and then test multiple features without requiring an initdb for each, it would be more palatable. > Adding tests in this manner doesn't seem scalable to me. I was thinking in having this be renamed src/test/modules/extensions/ and then the extension contained here would be renamed ext001_fk_tables or something like that; later we could ext002_something for testing some other angle of extensions, not necessarily pg_dump related. > I think we should rather add *one* test that does dump/restore over the > normal regression test database. Something similar to the pg_upgrade > tests. And then work at adding more content to the regression test > database - potentially sourcing from src/test/modules. That's another option, but we've had this idea for many years now and it hasn't materialized. As I recall, Andrew Dunstan has a module that tests cross-version pg_upgrade and one thing he does is dump both and compare; the problem is that there are differences, so he keeps a count of how many lines he expect to differ between any two releases. Or something like that. While it's a good enough start, I don't think it's robust enough to be in core. How would we do it? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
