Re: tap tests driving the database via psql

Craig Ringer <craig(at)2ndquadrant(dot)com> writes:
> On Sun, 28 Jul 2019 at 03:15, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> 1) Just depend on DBD::Pg being installed. It's fairly common, after
>> all. It'd be somewhat annoying that we'd often end up using a
>> different version of libpq than what we're testing against. But in
>> most cases that'd not be particularly problematic.

> I advocated for this in the past, and still think it's the best option.

I think the not-same-libpq issue would be a much bigger problem than either
of you are accounting for. Some off-the-top-of-the-head reasons:

* Since we'd have to presume a possibly-very-back-rev libpq, we could
never add tests related to any recent libpq bug fixes or new features.

* The system libpq might have a different idea of default port
and/or socket directory than the test build. Yeah, we could work
around that by forcing the choice all the time, but it would be a
constant hazard.

* We don't have control over what else gets brought in beside libpq.
Depending on the whims of the platform packagers, there might need
to be other parts of the platform's default postgres installation,
eg psql, sitting in one's PATH. Again, this wouldn't be too much
of a hazard for pre-debugged test scripts --- but it would be a huge
hazard for developers, who do lots of things manually and would always be
at risk of invoking the wrong psql. I learned long ago not to have any
part of a platform's postgres packages in place on my development systems,
and I will fight hard against any test procedure change that requires me
to do differently.

Now, none of these things are really a problem with DBD/DBI as such
--- rather, they are reasons not to depend on a pre-packaged build
of DBD::Pg that depends on a pre-packaged build of libpq.so.
I haven't looked at the size, or the license, of DBD::Pg ... but
could it be sane to include our own modified copy in the tree?

(Forking DBD::Pg would also let us add custom testing features
to it ...)

> The community IMO wastes *so* much time on not-invented-here make-work and
> on jumping through hoops to avoid depending on anything newer than the late
> '90s.

That's an unnecessary, and false, ad-hominem attack.

regards, tom lane