Craig Ringer <cr...@2ndquadrant.com> writes: > On Sun, 28 Jul 2019 at 03:15, Andres Freund <and...@anarazel.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