Tom Lane wrote: > The changes in t/002_pg_dump.pl largely failed to apply, which is > partially due to the age of the patch but IMO speaks more to the > unmaintainability of that TAP test. It still didn't run after I'd > manually fixed the merge failures, so I gave up in disgust and > did not push any of the test changes. If someone is excited enough > about testing this, they can submit a followon patch for that, > but I judge it not really worth either the human effort or the > future testing cycles. > > (Am I right in thinking that 002_pg_dump.pl is, by design, roughly > O(N^2) in the number of features tested? Ick.)
Yeah, that 002 test is pretty nasty stuff. I think we only put up with it because it's the only idea we've come up with; maybe there are better ideas. Crazy idea: maybe a large fraction of that test could be replaced with comparisons of the "pg_restore -l" output file rather than pg_dump's text output (i.e. the TOC entry for each object, rather than the object's textual representation.) Sounds easier in code than current implementation. Separately, verify that textual representation for each TOC entry type is what we expect. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
