Re: Peter Eisentraut 2014-11-03 <5457f54e.4020...@gmx.net> > On 11/2/14 2:00 PM, Noah Misch wrote: > >> Ick; I concur with your judgment on those aspects of the IPC::Cmd design. > >> Thanks for investigating. So, surviving options include: > >> > >> 1. Require IPC::Run. > >> 2. Write our own run() that reports the raw exit code. > >> 3. Distill the raw exit code from the IPC::Cmd::run() error string. > >> 4. Pass IPC::Run::run_forked() a subroutine that execs an argument list. > > > > FWIW, (3) looks most promising to me. That is to say, implement a reverse > > of > > IPC::Cmd::_pp_child_error(). Ugly to be sure, but the wart can be small and > > self-contained. > > I thank you for this research, but I suggest that we ship 9.4 as is, > that is with requiring IPC::Run and --enable-* option. All the possible > alternatives will clearly need more rounds of portability testing. We > can then evaluate these changes for 9.5 in peace.
Hrm. I spent some effort into getting the TAP tests to run on 9.4beta for Debian, and I've only now learned that 9.4.0 doesn't run them unless I say --enable-tap-tests. A short note to -packagers would have been nice, for a change so late in the release cycle... Christoph -- c...@df7cb.de | http://www.df7cb.de/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
