From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: TAP test breakage on MacOS X |
Date: | 2014-10-29 01:09:11 |
Message-ID: | 54503E37.2090909@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/28/14 12:46 AM, Noah Misch wrote:
> Agreed. Having this framework when the pg_upgrade test suite originated would
> have prevented acquiring parallel implementations in Perl and shell.
Yes, that was certainly a motivation, and I would like to continue work
on pg_upgrade testing.
> Concretely, that means
> discontinuing use of subplans and replacing IPC::Run with IPC::Cmd. (Windows
> systems probably need to install IPC::Run so IPC::Cmd can use it internally;
> that is okay.) If those restrictions make the test case developer experience
> much worse, though, I'll backpedal toward less portability.
I agree we should get rid of subplans. When I started out, they seemed
useful, to avoid this sort of thing found in the postgresql-common test
suite:
use Test::More tests => ($#MAJORS == 0) ? 1 : 103 * 3;
But as we are learning that they are a serious hindrance to portability,
I think we can do without them.
I have looked into IPC::Cmd, but the documentation keeps telling me that
to do anything interesting I have to have IPC::Run anyway. I'll give it
a try, though.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-10-29 01:16:50 | Re: how to handle missing "prove" |
Previous Message | Peter Eisentraut | 2014-10-29 01:01:12 | Re: TAP test breakage on MacOS X |