| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| 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:48:31 |
| Message-ID: | 12780.1564498111@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2019-07-30 09:40:54 -0400, Tom Lane wrote:
>> 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.
OK, so just lifting DBD::Pg in toto is out for license reasons.
However, maybe we could consider writing a new DBD driver from
scratch (while using a platform-provided DBI layer) rather than
doing everything from scratch. I'm not sure how much actual
functionality is in the DBI layer, so maybe that approach
wouldn't buy much.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2019-07-30 15:05:30 | Re: Parallel grouping sets |
| Previous Message | Andres Freund | 2019-07-30 14:42:49 | Re: tap tests driving the database via psql |