From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Testing with concurrent sessions |
Date: | 2010-01-07 16:46:53 |
Message-ID: | 4B460FFD.2070400@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David E. Wheeler wrote:
> On Jan 6, 2010, at 6:26 PM, Tom Lane wrote:
>
>
>> We have not yet fully accepted the notion that you must have Perl to
>> build (and, in fact, I am right now trying to verify that you don't).
>> I don't think that requiring Perl to test is going to fly.
>>
>
> I believe that the build farm already requires Perl, regardless of whether the PostgreSQL build itself requires it.
>
>
>
Unless I am mistaken, Perl is required in any case to build from CVS,
although not from a tarball.
DBI/DBD::pg is quite another issue, however. I have been deliberately
very conservative about what modules to require for the buildfarm, and
we have similarly (and I think wisely) been conservative about what
modules to require for Perl programs in the build process.
Using DBI/DBD::Pg would raise another issue - what version of libpq
would it be using? Not the one in the build being tested, that's for
sure. If you really want to use Perl then either a Pure Perl DBI driver
(which Greg has talked about) or a thin veneer over libpq such as we
used to have in contrib seems a safer way to go.
cheers
From | Date | Subject | |
---|---|---|---|
Next Message | Joachim Wieland | 2010-01-07 16:48:02 | Re: Hot Standy introduced problem with query cancel behavior |
Previous Message | Tom Lane | 2010-01-07 16:46:35 | Re: pg.dropped |