Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> Well, the current implementation compares a dozen of pg_dump output text
> files, three hundred lines apiece, against a thousand of regexes (give
> or take). Whenever there is a mismatch, what you get is "this regexp
> failed to match <three hundred lines>" (or sometimes "matched when it
> should have not"), so looking for the mismatch is quite annoying.
Yeah, I've been getting my nose rubbed in that over the past couple
days of pg_dump hacking: when you get a failure, the output is really
unfriendly, even by the seriously low standards of the rest of our
TAP tests.
I'm not sure if Alvaro's idea is the best way to improve that, but
it's something to think about.
The thing that was annoying me though is that it seems like every
test case interacts with every other test case, or at least way more
of them than one could wish, due to the construction of that big
hash constant. That's what I find unmaintainable.
regards, tom lane
