On Tue, Jul 30, 2019 at 07:20:53PM -0700, Andres Freund wrote:
> IDK, a minimal driver that just does what we need it to do is a few
> hundred lines, not more. And there's plenty of stuff that we simply
> won't be able to test with any driver that's not purposefully written
> for testing. There's e.g. basically no way with any of the drivers to
> test intentionally bogus sequences of protocol messages, yet that's
> something we really ought to test.
Yes, I don't know if a hundred of lines measure that correctly, but
really we should avoid bloating the stuff we rely on like by fetching
an independent driver if we finish by not using most of its features.
300~500 lines would be fine for me, 10k definitely not.
> I've written custom hacks^Wprograms to tests things like that a few
> times. That really shouldn't be necessary.
Mine are usually plain hacks :), and usually on top of libpq but I
have done some python-ish script to send bogus and hardcoded protocol
messages. If we can automate a bit this area, that could be useful.
>> Perl modules support local installations. Would it be reasonable to require
>> DBI to be present, then rebuild DBD::Pg against our libpq during our own
>> test infra compilation, and run it with a suitable LD_LIBRARY_PATH or using
>> rpath? That'd actually get us a side-benefit of some test coverage of
>> DBD::Pg and libpq.
>
> You're intending to download DBD::Pg? Or how would you get around the
> licensing issues? Downloading it will have some issues too: For one at least I
> often want to be able to run tests when offline; there's security
> concerns too.
As Craig has mentioned CPAN can be configured to install all the
libraries for a local user, so there is no need to be online if a copy
has been already downloaded.
--
Michael