Add extension update test via pgxntool test-build

[jnasbyupgrade]

Add full update+upgrade testing to the suite: test/deps.sql now selects between three install modes via a TEST_LOAD_SOURCE GUC - fresh (CREATE EXTENSION at current), update (installs 0.9.6, then ALTER EXTENSION UPDATE, exercised by make test-update), and existing (asserts an already-installed extension is present and current, touching nothing else, for use against a real pg_upgrade'd or out-of-band-updated database). A second, independent TEST_SCHEMA switch runs the whole suite both WITHOUT specifying a schema at all (CREATE EXTENSION with no targeting, landing wherever the session's own ambient search_path resolves) and WITH one explicitly targeted, using a name that requires SQL identifier quoting - both legs run in CI, neither redundant with the other. See test/README.md for the full breakdown of both switches and exactly what drives the need for the two remaining expected/extension_tests*.out variants.

A dependency-guard technique (bin/test_existing.sql/*.sql: a view with a hard pg_depend edge to a stable, never-dropped extension member) proves an install/update/pg_upgrade sequence didn't silently drop and reinstall the extension it's meant to be testing, which would otherwise let a regression hide behind a fresh reinstall; bin/test_existing factors install -> plant guard -> update/upgrade -> assert -> drop guard -> run suite into one committed, parameterized script instead of duplicating it as inline YAML. Three new CI jobs exercise all of this on every push: extension-update-test (0.9.6 -> current, across a PostgreSQL x schema matrix), pg-upgrade-test (a real binary pg_upgrade across PostgreSQL majors, old_pg/new_pg x schema legs), and a docs-only gate that also derives the PostgreSQL-major matrix list from a single set of constants (so a new major is a one-line change, not an edit in several jobs) feeding a stable all-checks-passed required check. ci.yml now leads with a top-of-file summary comment covering the whole matrix strategy.

Removed test/sql/simple.sql and test/sql/sanity.sql. simple.sql existed to exercise "the other" schema before TEST_SCHEMA existed, dressed up as an on-search-path test, but the extension's own functions are all schema-qualified via ncs() regardless of search_path, so its search_path manipulation never actually changed anything - the schema coverage it stood in for is now done properly (and more thoroughly) by the TEST_SCHEMA matrix on extension_tests.sql directly. sanity.sql's two direct null_count() calls turned out to be a strict subset of what test__functionality's bag_eq comparisons already cover (the same 8-row test_data set exercises every null-count combination those two calls checked, and more). Confirmed no coverage was lost either time before removing.

Adapted from Postgres-Extensions/cat_tools's own update+upgrade testing where it differs: no bridge-update leg is needed, since count_nulls has no pg_upgrade-unsafe old version to work around (a real, not rare, risk for any extension - just not one count_nulls happens to have); the dependency guard is dropped before the suite runs, rather than left standing through it, since count_nulls's suite has its own legitimate (harmless, rolled-back) DROP EXTENSION test that would otherwise collide with it; and no every-major stepwise pg_upgrade climb, since count_nulls has nothing catalog-touching that would benefit from it. The TEST_SCHEMA/quoting design was arrived at independently here, before noticing cat_tools has its own open PR doing the same thing for test role names - worth noting as a broadly useful pattern rather than a one-off.

Also simplified bin/test_existing.sql/plant_guard.sql (a single quote_ident()-built prefix variable instead of branching the whole view definition) and test/sql/extension_tests.sql's two schema-aware test__* functions (schema passed as a function parameter default instead of a current_setting() workaround inside the plpgsql body, since psql substitution doesn't reach inside dollar-quoted bodies but does reach a parameter default).

Deliberately NOT doing right now, but captured as a comment in test/core/functions.sql for next time that file is substantially touched: migrating the main suite's install to pgxntool's test/install feature (cat_tools's own pattern for centralizing fresh/update/existing switching, an independent argument for it regardless of the schema question), and revisiting the debuggability tradeoff of this file's shared/loop-driven design versus interactively \i-ing a traditional, self-contained test file in psql - the actual reason count_nulls originally had separate smoke-test files like the two just removed, worth an intentional replacement if this ever becomes a real problem rather than just letting it stay absent.

test/expected/extension_tests.out was regenerated via make results for the new default (TEST_SCHEMA empty). Two pg_regress alternate-expected-output files cover the two other cases that produce genuinely different (not wrong) text: _1.out for TEST_SCHEMA=Quoted, and _2.out for the empty-schema case as exercised by a bare standalone psql session (the extension-update-test/pg-upgrade-test jobs) rather than the in-suite pg_regress session, which lands in a different real schema than the in-suite case does.

Verified locally against live PG12/PG17 clusters, including a real binary pg_upgrade PG12->PG17 run (extension carried at 0.9.6, updated to 1.0.0, dependency guard proven through every step) before trusting any of this as CI YAML; make test and make test-update pass cleanly on both PG17 and PG12, with and without an explicit TEST_SCHEMA.

Stacked on #10 (now merged).

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: b58bf997-1ae5-4cf0-8a2f-9b17332c29f3

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch extension-update-test

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}