Re: libpq URI and regression testing - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: libpq URI and regression testing
Date
Msg-id 4F8DBE96.5080601@dunslane.net
Whole thread Raw
In response to Re: libpq URI and regression testing  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: libpq URI and regression testing
Re: libpq URI and regression testing
List pgsql-hackers

On 04/17/2012 02:47 PM, Alvaro Herrera wrote:
> Excerpts from Peter Eisentraut's message of mar abr 17 15:41:04 -0300 2012:
>> On tis, 2012-04-17 at 10:47 -0300, Alvaro Herrera wrote:
>>> What's the preferred way to make it automatically tested as much as
>>> possible?  I know the buildfarm does not run "installcheck-world", so if
>>> we want it there, it'd need a bit more code on the client side.  I think
>>> it would be wise to have it also run on installcheck-world.
>> It was agreed during the patch discussion that it shouldn't be run
>> automatically.
> Oh, okay.  I didn't notice that.  I guess we should issue a
> call-for-testing, then, so that we ensure it works (FSVO works) in all
> (FSVO all) platforms.
>
>>> Hmm.  Just had this thought: not all platform support the same socket
>>> types.  Maybe we should have separated the .in file in three parts:
>>> IPv4, IPv6, unix-domain socket.  That way each platform would only run
>>> tests that pertain to it.  Right now there's a single "regress.in" file
>>> that lists all the tests.
>> That's one reason for that, but there are probably others in the way of
>> making this fully portable and automatable.


This test setup also appears to labor under the illusion that we live in 
a Unix-only world. And for no good reason that I can tell. The shell 
script should be ripped out and replaced by a perl script which could 
actually be used on any windows build host. The MSVC build system also 
needs adjusting to make it build the test driver, at least.

cheers

andrew



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Parameterized-path cost comparisons need some work
Next
From: Tom Lane
Date:
Subject: Re: Parameterized-path cost comparisons need some work