Re: Handle TEMP_CONFIG for pg_regress style tests in pg_regress.c

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Handle TEMP_CONFIG for pg_regress style tests in pg_regress.c
Дата
Msg-id 3169479.1676823218@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Handle TEMP_CONFIG for pg_regress style tests in pg_regress.c  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: Handle TEMP_CONFIG for pg_regress style tests in pg_regress.c  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: Ignoring BRIN for HOT updates (was: -udpates seems broken)
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: Add LZ4 compression in pg_dump