Re: [HACKERS] PROVE_FLAGS - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] PROVE_FLAGS
Date
Msg-id CA+TgmoZ85YAQbiJoRxUTrypK6Hk3rUduZWrQbevoBG7cjvGX+Q@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] PROVE_FLAGS  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Responses Re: [HACKERS] PROVE_FLAGS  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
List pgsql-hackers
On Tue, May 16, 2017 at 9:20 PM, Andrew Dunstan
<andrew.dunstan@2ndquadrant.com> wrote:
> Inheriting variables from the environment is a part of make by design.
> We have PG_PROVE_FLAGS for our own forced settings.

I don't buy this argument.  We've had previous cases where we've gone
through and added -X to psql invocations in the regression tests
because, if you don't, some people's .psqlrc files may cause tests to
fail, which nobody wants.  The more general principle is that the
regression tests should ideally pass regardless of the local machine
configuration.  It's proven impractical to make that universally true,
but that doesn't make it a bad goal.  Now, for all I know it may be
that setting PROVE_FLAGS can never cause a regression failure, but I
still tend to agree with Peter that the regression tests framework
should insulate us from the surrounding environment rather than
absorbing settings from it.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advanceof pgindent run.
Next
From: Tom Lane
Date:
Subject: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)