Re: Recent pg_regress changes break testing under SELinux

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Recent pg_regress changes break testing under SELinux
Date: 2008-01-18 22:37:24
Message-ID: 13721.1200695844@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> Tom Lane wrote:
>> 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?

I was trying to avoid that, but only because it'd make the patch bigger.
It would be one way to resolve the above gripes.

But I'm still thinking that it's fairly silly to expect Windows users to
type out the equivalent of

./pg_regress --psqldir=$(PSQLDIR) --schedule=$(srcdir)/parallel_schedule --srcdir=$(abs_srcdir) --multibyte=$(MULTIBYTE) --load-language=plpgsql $(MAXCONNOPT) $(NOLOCALE)

especially when no other platform is that hard. (Admittedly, some of
these switches have usable defaults, but many don't.) So it really
seems like the right answer is a .BAT script, and I'm kinda surprised
to hear there's not one already.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2008-01-18 23:16:07 Re: Recent pg_regress changes break testing under SELinux
Previous Message Magnus Hagander 2008-01-18 22:21:23 Re: Recent pg_regress changes break testing under SELinux