meson/testwrap: support EXTRA_REGRESS_OPTS environment variable

Core Problem: Test Runner Parity Between Autoconf and Meson Builds

PostgreSQL's dual build-system era (autoconf + meson, with autoconf scheduled for removal) has created numerous small-but-annoying gaps where behavior that "just worked" under make needs to be explicitly re-plumbed through the meson harness. This thread surfaces one such gap in the regression test infrastructure: the inability to pass arbitrary flags to pg_regress when invoked via meson test.

The --use-existing Use Case

pg_regress supports a --use-existing flag that tells it not to create a fresh regression database but instead run the schedule against an already-populated one. This is important for:

1. Running installcheck-style workflows against a live server — useful when debugging, when testing extensions, or when validating that a server built one way behaves correctly against a regression database populated another way.
2. Post-mortem inspection — after a failure, keeping the regression DB around and re-running subsets of tests against it without the expensive re-setup of test_setup, create_index, etc.

Under autoconf this was trivial:

EXTRA_REGRESS_OPTS="--use-existing" make installcheck

The Makefile infrastructure appends $(EXTRA_REGRESS_OPTS) to the pg_regress invocation, so the flag reaches the test driver while the schedule remains intact.

Why Meson Breaks This

Meson wraps each test invocation through src/tools/testwrap, which receives a fixed argv assembled by meson.build. The only user-facing escape hatch is the TESTS environment variable, which is consumed by testwrap and replaces the schedule/test-list arguments entirely — it does not augment them.

Bertrand's empirical discovery illustrates the asymmetry:

• TESTS="test_setup create_index memoize --use-existing" — works by accident, because the named tests supply the schedule and --use-existing rides along as a pg_regress flag.
• TESTS="--use-existing" alone — fails with SKIP because there are zero test names; pg_regress has nothing to run.

There is thus no supported way, under meson, to run the entire schedule against an existing database. This is a real functional regression relative to autoconf.

Proposed Solution

The patch in this thread adds EXTRA_REGRESS_OPTS handling in src/tools/testwrap. When the environment variable is set, its contents are appended to the constructed command line for test kinds that use pg_regress semantics: regress, isolation, and ecpg. This is a direct port of the autoconf Make variable to the meson driver, preserving the interface contract users already know.

Design characteristics worth noting:

• Appending, not replacing: unlike TESTS, EXTRA_REGRESS_OPTS is additive. This is the right layering — the schedule is determined by the build system; user-supplied flags modify pg_regress behavior orthogonally.
• Scoped to pg_regress-family drivers: TAP tests and other test kinds are untouched, avoiding accidental leakage of flags to drivers that wouldn't understand them.
• Environment-variable interface: chosen over a meson option/CLI flag because meson's test subcommand doesn't provide a clean way to forward arbitrary strings down to the wrapper. An env var is also consistent with autoconf precedent, minimizing documentation burden and muscle-memory retraining.

Duplicate Work and Resolution

Andreas Karlsson pointed out that he already had an equivalent patch in the current commitfest (entry 6361) that reviewers considered substantively acceptable, blocked only on missing documentation. Bertrand withdrew his patch in deference, which is the correct outcome — the two implementations target identical behavior and splitting review effort would be wasteful.

The remaining gating factor is documentation. Given meson usage is steadily replacing autoconf, the wiki's meson page ([2] in the thread) and the official "Regression Tests" chapter both need to describe EXTRA_REGRESS_OPTS as the supported augmentation mechanism, and likely contrast it with TESTS (replacement semantics) to preempt the exact confusion Bertrand hit.

Architectural Implications

This is a small patch but it reflects a recurring theme in the meson transition: behavioral parity is not automatic. Every implicit Make convention — variable append points, target composition, environment variable conventions — must be audited and reimplemented in the testwrap/meson.build layer. Threads like this one are effectively an ongoing regression-parity audit, and the test infrastructure in particular has been a frequent source of such findings because developers exercise these paths constantly and notice friction quickly.

A secondary observation: testwrap is becoming the de-facto policy layer between meson's generic test runner and PostgreSQL's test semantics. As more escape hatches accumulate there (TESTS, now EXTRA_REGRESS_OPTS, previously PG_TEST_EXTRA and friends), it may eventually warrant consolidation or at least a single documented surface listing every recognized env var.