Re: contrib/sepgsql regression tests are a no-go

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: contrib/sepgsql regression tests are a no-go
Date: 2011-09-26 14:04:10
Message-ID: 5269.1317045850@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On sn, 2011-09-25 at 23:49 -0400, Robert Haas wrote:
>> In fact, I've been wondering if we ought to go a step further and not
>> recurse into the sepgsql directory for *any* of the targets. Then we
>> could get rid of the associated configure option, which no longer
>> serves any other purpose, and just say that if you want to build (or
>> regression-test) sepgsql, well, you gotta go to that directory and do
>> it by hand.

> I'm not in favor of that. It's nice to have a uniform interface that
> decides what to build.

Well, the right fix is to fix the sepgsql regression tests so that they
adhere to the uniform model of being something you can run without
destructive modifications to the host system. What's being discussed at
the moment is the least messy stopgap we can have until the tests are
fixed. I think that just taking sepgsql out of the subdirectory list
(except for "make clean") might well be the most attractive workaround.

Another possibility is to remove the Makefile's knowledge of how to run
the tests, and change chkselinuxenv into something that both verifies
the environment and then launches the tests.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-09-26 14:06:45 Re: [v9.2] Fix Leaky View Problem
Previous Message Merlin Moncure 2011-09-26 14:02:04 Re: Is there any plan to add unsigned integer types?