>>> Is this issue *really* worth expending test cycles on forevermore?
>
>> With this argument consistently applied, postgres code coverage is
>> consistently weak, with 25% of the code never executed, and 15% of
>> functions never called. "psql" is abysmal, "libpq" is really weak.
>
> It's all a question of balance. If you go too far in the other
> direction, you end up with test suites that take an hour and a half
> to run so nobody ever runs them (case in point, mysql). I'm all for
> improving coverage in meaningful ways --- but cases like this seem
> unlikely to be worth ongoing expenditures of testing effort.
Sure.
I think there is room for several classes of tests, important ones always
run and others run say by the farm, and I thought that is what TAP tests
were for, given they are quite expensive anyway (eg most TAP test create
their own postgres instance).
So for me the suggestion was appropriate for a pgbench-specific TAP test.
--
Fabien.