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
