Context
2.3.0 (#83, fixing #79/#49/#35) added an explicit `installcheck: install` prerequisite so `make installcheck`/`make test` can no longer run pg_regress before the extension is actually installed - a real, correct fix for a real bug (previously, unrelated prerequisites of `test` could run in either order).
The new problem
That same fix closes off a previously-viable, legitimate pattern: testing an extension that was deployed WITHOUT any filesystem install at all - e.g. via AWS pg_tle's database-backed registration catalog, where the whole point is proving `CREATE EXTENSION` resolves through pg_tle's registration rather than a `.control` file on disk. `bin/assert_fs_clean`-style checks (used by `Postgres-Extensions/pg_count_nulls`'s own `pg-tle-test` job, modeled on `cat_tools`'s) actively fail the build if a stray `.control` file shows up - but `installcheck` now unconditionally runs `make install` first, which writes exactly that file, making it structurally impossible to run the real pgTAP suite against a pg_tle-only deployment via the normal `make test`/`make installcheck` path.
Confirmed directly: with a fresh pgxntool 2.3.0 checkout, deleting the installed `.control` file and running `make -n installcheck` shows the dry-run plan re-running the full `install` recipe (recreating `.control` and every versioned SQL file) before ever reaching the actual `pg_regress` invocation - there is no way to reach `installcheck`'s pg_regress call without `install` running first.
Before 2.3.0, a project could route around this by calling `make testdeps` then `make installcheck` directly, since neither declared an `install` dependency on its own (relying only on test's TEST_DEPS listing them side by side, unordered). That workaround is exactly what the #79 fix correctly closed, as an unintended side effect for this specific use case.
Ask
Some way to run the real pg_regress invocation without a filesystem install happening first - a few possible shapes, no strong opinion on which:
- A documented variable (e.g. `PGXNTOOL_SKIP_INSTALL_PREREQ=yes`) that keeps `installcheck`'s pg_regress recipe but skips the new `install` prerequisite specifically, for callers who already know the extension is present some other way (a real `pg_upgrade`, an out-of-band `CREATE EXTENSION`, or a pg_tle registration).
- A separate target (e.g. `installcheck-only` or similar) that's guaranteed to never pull in `install`, documented as the deliberate escape hatch for this case, so `installcheck` itself can stay simple and always-safe.
Happy to be pointed at a workaround I've missed instead, if one already exists.
Where this came up
Found while porting `Postgres-Extensions/cat_tools`'s pg_tle-update-path testing pattern (mentioned in `README.asc`'s U&U section) onto `pg_count_nulls` after adopting 2.3.0 - the fresh-install pg_tle smoke test (which never calls `installcheck`) is unaffected, but extending it to also exercise the update path via the real pgTAP suite hits this directly.
Context
2.3.0 (#83, fixing #79/#49/#35) added an explicit `installcheck: install` prerequisite so `make installcheck`/`make test` can no longer run pg_regress before the extension is actually installed - a real, correct fix for a real bug (previously, unrelated prerequisites of `test` could run in either order).
The new problem
That same fix closes off a previously-viable, legitimate pattern: testing an extension that was deployed WITHOUT any filesystem install at all - e.g. via AWS pg_tle's database-backed registration catalog, where the whole point is proving `CREATE EXTENSION` resolves through pg_tle's registration rather than a `.control` file on disk. `bin/assert_fs_clean`-style checks (used by `Postgres-Extensions/pg_count_nulls`'s own `pg-tle-test` job, modeled on `cat_tools`'s) actively fail the build if a stray `.control` file shows up - but `installcheck` now unconditionally runs `make install` first, which writes exactly that file, making it structurally impossible to run the real pgTAP suite against a pg_tle-only deployment via the normal `make test`/`make installcheck` path.
Confirmed directly: with a fresh pgxntool 2.3.0 checkout, deleting the installed `.control` file and running `make -n installcheck` shows the dry-run plan re-running the full `install` recipe (recreating `.control` and every versioned SQL file) before ever reaching the actual `pg_regress` invocation - there is no way to reach `installcheck`'s pg_regress call without `install` running first.
Before 2.3.0, a project could route around this by calling `make testdeps` then `make installcheck` directly, since neither declared an `install` dependency on its own (relying only on
test's TEST_DEPS listing them side by side, unordered). That workaround is exactly what the #79 fix correctly closed, as an unintended side effect for this specific use case.Ask
Some way to run the real pg_regress invocation without a filesystem install happening first - a few possible shapes, no strong opinion on which:
Happy to be pointed at a workaround I've missed instead, if one already exists.
Where this came up
Found while porting `Postgres-Extensions/cat_tools`'s pg_tle-update-path testing pattern (mentioned in `README.asc`'s U&U section) onto `pg_count_nulls` after adopting 2.3.0 - the fresh-install pg_tle smoke test (which never calls `installcheck`) is unaffected, but extending it to also exercise the update path via the real pgTAP suite hits this directly.