Handle TEMP_CONFIG for pg_regress style tests in pg_regress.c
В списке pgsql-hackers по дате отправления:
| От | Andres Freund |
|---|---|
| Тема | Handle TEMP_CONFIG for pg_regress style tests in pg_regress.c |
| Дата | |
| Msg-id | 20230218202611.cp7ke2tz5lnafu5z@awork3.anarazel.de обсуждение исходный текст |
| Ответы |
Re: Handle TEMP_CONFIG for pg_regress style tests in pg_regress.c
|
| Список | pgsql-hackers |
Hi, 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. It can be implemented differently, e.g. by adding the parameter dynamically in the wrapper around pg_regress, but I don't see an advantage in that. Patch attached. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера