Hello Tom,
Pushed, with some minor fooling with comments and after running it through perltidy. (I have no opinions about Perl code formatting, but perltidy does ...)
Why not. I do not like the result much, but it homogeneity is not a bad thing.
The only substantive change I made was to drop the test that attempted to connect to no-such-host.postgresql.org. That's (a) unnecessary, as this is a test of pgbench not libpq; (b) likely to provoke a wide range of platform-specific error messages, which we'd have to account for given that the test is looking for specific output; and (c) likely to draw complaints from buildfarm owners and packagers who do not like test scripts that try to make random external network connections.
Ok. Note that it was only an unsuccessful DNS request, but I understand the concern. The libpq tap test mostly focus on url parsing but seem to include host names ("example.com"/host) and various IPs.
Like you, I'm a bit worried about the code for extracting an exit status from IPC::Run::run. We'll have to keep an eye on the buildfarm for a bit. If there's any trouble, I'd be inclined to drop it down to just success/fail rather than checking the exact exit code.
Ok. If this occurs, there is a $windows_os variable that can be tested to soften the test only if necessary, and keep the exact check for systems that can.
Thanks for the review, the improvements and the push. Now the various patches about pgbench in the queue should include tap-tests.
Hopefully one line will be greener on https://coverage.postgresql.org/. -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
