Re: Recent pg_regress changes break testing under SELinux - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Recent pg_regress changes break testing under SELinux
Date
Msg-id 47912663.3010607@hagander.net
Whole thread Raw
In response to Re: Recent pg_regress changes break testing under SELinux  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Recent pg_regress changes break testing under SELinux  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> Tom Lane wrote:
>>> Who decided this part of pg_regress.c was a good idea?
> 
>> Hmm, AFAICS it was applied by me in 1.26, a patch from Magnus
>> apparently.  This was quite some time ago!  I think I just passed that
>> part verbatim from Magnus' patch.
> 
> Hmm ... I wonder if the unstated agenda was to run the regression tests
> without having any supporting Makefile?

AFAIK, that was the *stated* agenda. Or rather, a part of the stated agenda.


> I'd be willing to make it #ifdef WIN32, instead of diking it out entirely,
> if that's what the problem is.  I would prefer to remove it though.
> The original design had only the Makefile knowing exactly where the
> testtablespace directory lurks, making it changeable in one place,
> and also confining the whole business to src/test/regress which is good
> because none of the other uses of pg_regress need it.  As CVS tip
> stands, the location of testtablespace is hard-wired into the pg_regress
> executable, and I think it's mostly blind accident that it doesn't
> clutter contrib/* and src/pl/* with testtablespace directories.

Commandline parameter, perhaps?


> At this point what I'd really prefer is that pg_regress be completely
> uninvolved with testtablespace, which we could manage by getting rid
> of @testtablespace@ in the regression test files in favor of
> @abs_builddir@/testtablespace.  This would mean that both the Makefile
> and the regression test files know where the directory lurks, but either
> of those are easier to change than a precompiled binary.
> 
> Now this isn't gonna work if there's a prerequisite for pg_regress
> to execute without any external setup, but surely we don't expect
> users to enter all its switch arguments by hand.  What's the actual
> intended arrangement on Windows ... is there a .BAT script or something
> that could make the directory?

Yeah, there could be that. The idea was to be able to run it without the 
need for mingw - meaning no Makefile support and no shellscript. But 
.BAT is supported on all Windows.

//Magnus



pgsql-hackers by date:

Previous
From: "Pavel Stehule"
Date:
Subject: Re: proposal: generic function, constructor function
Next
From: Tom Lane
Date:
Subject: Re: Recent pg_regress changes break testing under SELinux