Context
extension-update-test and pg-upgrade-test assert that the post-update database looks structurally correct (schema location, function definitions, etc. via the shared suite / bin/compare_fresh_vs_update). But nothing currently proves the ALTER EXTENSION ... UPDATE code path specifically executed — a bug that silently fell through to a fresh install instead (e.g. a broken mode-detection GUC read, a TEST_LOAD_SOURCE propagation regression) could produce an end state indistinguishable from a real update, and the suite would still pass.
For the TEST_SCHEMA dimension we get this protection basically for free: test__check_ncs explicitly asserts the extension landed in the expected schema, so a stale/wrong install is caught incidentally. There's no equivalent signal for load mode — "did an update actually run" isn't something the current assertions can distinguish from "was this a fresh install all along."
Idea (not yet designed or implemented)
Capture direct evidence that ALTER EXTENSION ... UPDATE fired, rather than only checking the resulting object state. Sketch: a permanent (non-temp) table, populated via an event trigger (e.g. on ddl_command_end, filtered to ALTER EXTENSION), that records when/that an update ran. test/install/load.sql's update mode (or the existing-mode assertions) could then check for that record directly, the same way the dependency-guard technique proves a real migrated object survived rather than a fresh recreate.
Open questions to work out if/when this gets picked up:
- Does this need to be part of
count_nulls itself (shipped in the extension, at least for test builds), or can it be planted purely from the test harness side?
- Event-trigger-based approach vs. something simpler (e.g. a marker row written directly by the update script)?
- Worth generalizing into pgxntool's own U&U testing pattern once proven out here, given the same gap likely exists in
cat_tools and any other extension using this pattern?
Status
Idea only — flagged during review of PR #32 (phase5-cross-schema). Not blocking; filed for future investigation.
Context
extension-update-testandpg-upgrade-testassert that the post-update database looks structurally correct (schema location, function definitions, etc. via the shared suite /bin/compare_fresh_vs_update). But nothing currently proves theALTER EXTENSION ... UPDATEcode path specifically executed — a bug that silently fell through to a fresh install instead (e.g. a broken mode-detection GUC read, aTEST_LOAD_SOURCEpropagation regression) could produce an end state indistinguishable from a real update, and the suite would still pass.For the
TEST_SCHEMAdimension we get this protection basically for free:test__check_ncsexplicitly asserts the extension landed in the expected schema, so a stale/wrong install is caught incidentally. There's no equivalent signal for load mode — "did an update actually run" isn't something the current assertions can distinguish from "was this a fresh install all along."Idea (not yet designed or implemented)
Capture direct evidence that
ALTER EXTENSION ... UPDATEfired, rather than only checking the resulting object state. Sketch: a permanent (non-temp) table, populated via an event trigger (e.g. onddl_command_end, filtered toALTER EXTENSION), that records when/that an update ran.test/install/load.sql's update mode (or the existing-mode assertions) could then check for that record directly, the same way the dependency-guard technique proves a real migrated object survived rather than a fresh recreate.Open questions to work out if/when this gets picked up:
count_nullsitself (shipped in the extension, at least for test builds), or can it be planted purely from the test harness side?cat_toolsand any other extension using this pattern?Status
Idea only — flagged during review of PR #32 (
phase5-cross-schema). Not blocking; filed for future investigation.