Re: TestLib::command_fails_like enhancement

From: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
To: Mark Dilger <hornschnorter(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: TestLib::command_fails_like enhancement
Date: 2019-11-11 16:48:25
Message-ID: 37d66e69-d51a-a6d2-79f6-10ed6071be3e@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 11/9/19 8:25 AM, Andrew Dunstan wrote:
> OK, I agree that we're getting rather baroque here. I could go with your
> suggestion of YA function, or possibly a solution that simple passes any
> extra arguments straight through to IPC::Run::run(), e.g.
>
> command_fails_like(
>       [ 'pg_dump', 'qqq', 'abc' ],
>       qr/\Qpg_dump: error: too many command-line arguments (first is
> "abc")\E/,
>       'pg_dump: too many command-line arguments',
>       '<pty<', \$eof_in);
>
> That means we're not future-proofing the function - we'll never be able
> to add more arguments to it, but I'm not really certain that matters
> anyway. I should note that perlcritic whines about subroutines with too
> many arguments, so making provision for more seems unnecessary anyway.
>
> I don't think this is worth spending a huge amount of time on, we've
> already spent more time discussing it than it would take to implement
> either solution.
>
>

On further consideration, I'm wondering why we don't just
unconditionally use a closed input pty for all these functions (except
run_log). None of them use any input, and making the client worry about
whether or not to close it seems something of an abstraction break.
There would be no API change at all involved in this case, just a bit of
extra cleanliness. Would need testing on Windows, I'll go and do that now.

Thoughts?

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-11-11 16:53:40 Re: Coding in WalSndWaitForWal
Previous Message Dave Cramer 2019-11-11 16:15:45 Re: Binary support for pgoutput plugin