Re: Handle TEMP_CONFIG for pg_regress style tests in pg_regress.c
От | Peter Eisentraut |
---|---|
Тема | Re: Handle TEMP_CONFIG for pg_regress style tests in pg_regress.c |
Дата | |
Msg-id | 48568ed7-1ccd-0ca9-aa31-e51e9df2c99d@enterprisedb.com обсуждение исходный текст |
Ответ на | Handle TEMP_CONFIG for pg_regress style tests in pg_regress.c (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Handle TEMP_CONFIG for pg_regress style tests in pg_regress.c
|
Список | pgsql-hackers |
On 18.02.23 21:26, Andres Freund wrote: > When building with meson, TEMP_CONFIG is supported for TAP tests, but doesn't > do anything for regress/isolation. > > The reason for that is that meson's (and ninja's) architecture is to separate > "build setup" from the "build/test/whatever" stage, moving dynamism (and more > costly operations) to the "setup" phase. > > In this case the implication is that the command line for the test isn't > re-computed dynamically. But pg_regress doesn't look at TEMP_CONFIG, it just > has a --temp-config=... parameter, that src/Makefile.global.in dynamically > adds if TEMP_CONFIG is set. > > In contrast to that, TEMP_CONFIG support for tap tests is implemented in > Cluster.pm, and thus works transparently. > > 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. pg_regress already looks at a bunch of temporary variables > (e.g. PG_REGRESS_SOCK_DIR, PG_TEST_USE_UNIX_SOCKETS), so this isn't really > breaking new ground. I'm having a hard time understanding what TEMP_CONFIG is for. It appears that the intention is to allow injecting arbitrary configuration into the tests? In that case, I think your proposal makes sense. But I don't see this documented, so who knows what it is actually used for.
В списке pgsql-hackers по дате отправления: