Re: tap tests driving the database via psql

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: tap tests driving the database via psql
Date: 2019-07-30 14:42:49
Message-ID: 20190730144249.y47vmmlg7lgra4vi@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2019-07-30 09:40:54 -0400, Tom Lane wrote:
> 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:

I came to the same conclusion?

> 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?

I had that as an alternative too. I think the license (Artistic v1/GPL
v1) probably makes that non-feasible. The pure-perl version of DBI
probably would otherwise be realistic.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-07-30 14:48:31 Re: tap tests driving the database via psql
Previous Message Sehrope Sarkuni 2019-07-30 14:27:26 Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)