Re: Handle TEMP_CONFIG for pg_regress style tests in pg_regress.c - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Handle TEMP_CONFIG for pg_regress style tests in pg_regress.c
Date
Msg-id 3169479.1676823218@sss.pgh.pa.us
Whole thread Raw
In response to Re: Handle TEMP_CONFIG for pg_regress style tests in pg_regress.c  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Handle TEMP_CONFIG for pg_regress style tests in pg_regress.c
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> On 2023-02-19 Su 02:25, Peter Eisentraut wrote:
>> On 18.02.23 21:26, Andres Freund wrote:
>>> My inclination is to move TEMP_CONFIG support from the Makefile to
>>> pg_regress.c. That way it's consistent across the build tools and isn't
>>> duplicated.

>> I'm having a hard time understanding what TEMP_CONFIG is for.

> It's used by the buildfarm to add the extra config settings from its 
> configuration file.

I have also used it manually to inject configuration changes into
TAP tests, for instance running them with debug_discard_caches = 1.
It's quite handy, but I agree the lack of documentation is bad.

It looks to me like pg_regress already does implement this; that
is, the Makefiles convert TEMP_CONFIG into a --temp-config switch
to pg_[isolation_]regress.  So if we made pg_regress responsible
for examining the envvar directly, very little new code would be
needed.  (Maybe net negative code if we remove the command line
switch, but I'm not sure if we should.)  What we'd lose is the
ability to write
    make TEMP_CONFIG=foo check
but I wouldn't miss that.  Having a uniform rule that TEMP_CONFIG
is an environment variable and nothing else seems good.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Ignoring BRIN for HOT updates (was: -udpates seems broken)
Next
From: Tomas Vondra
Date:
Subject: Re: Add LZ4 compression in pg_dump