Add extension update test via pgxntool test-build

[jnasbyupgrade]

Summary

Stacked on #10 (needs the 1.0.0 bump — updating from 0.9.6 is a no-op until then).

Two complementary pieces, modeled on cat_tools's pattern (now written up generally at ~/advanced-extension-testing.md, reference impl on their new_functions branch / PR #16, plus CI details on PR #37):

• test/build/upgrade.sql (pgxntool 2.1.0's test-build feature): a fast smoke check. Installs the oldest version we still ship a full script for (0.9.6), then ALTER EXTENSION count_nulls UPDATE, rolled back. Cheap, fails fast, but only proves the update completes — it never exercises the extension's actual behavior.
• test/deps.sql mode toggle: the real coverage. test/deps.sql is loaded by every test file, and now installs either fresh (current version) or via the update path (0.9.6 → ALTER EXTENSION UPDATE), selected by a count_nulls.test_load_mode placeholder GUC that the Makefile sets via PGOPTIONS (TEST_LOAD_SOURCE=fresh|update, default fresh). make test-update reruns the entire existing suite (extension_tests, sanity, simple) against the updated install, comparing against the same expected/*.out used by make test — proving the update behaves identically to a fresh install, not just that it doesn't error.

Terminology note (per the writeup, "the single most common mistake here"): update = extension-level (ALTER EXTENSION UPDATE); upgrade = cluster-level (pg_upgrade), a separate axis this PR doesn't cover. Variable/GUC names use "update" throughout.

This is adapted from cat_tools's test/install/load.sql pattern, but count_nulls's suite already installs the extension per test file (into different schemas, to test schema-qualification behavior), rather than once globally — so a shared test/install fixture didn't fit cleanly. The test/deps.sql-level toggle achieves the same "actually run the suite against the update" goal without restructuring that existing per-file install pattern. The reference implementation's target design also adds TEST_UPDATE_FROM/TEST_UPDATE_TO parameterization and an existing mode (for testing state left by a real pg_upgrade) — not needed here yet since count_nulls only has one meaningful update floor (0.9.6) and no pg_upgrade CI job exists yet.

sql/count_nulls--0.9.6.sql isn't picked up by base.mk's DATA wildcard (only upgrade-diff scripts and the current version file are), so it's added explicitly — filed as a pgxntool bug: Postgres-Extensions/pgxntool#48.

Next step (separate PR): wire make test-update into .github/workflows/ci.yml across the PG version matrix, following the extension-update-test job pattern from cat_tools PR #37 (dynamic version assertions read from the build rather than hardcoded, with empty-value guards).

Test plan

• make test passes on PG17 and PG12 (fresh mode)
• make test-update passes on PG17, same expected output as fresh mode
• Manually verified the GUC-selected branch actually runs (update mode ends at extversion 1.0.0 via CREATE EXTENSION VERSION '0.9.6' + ALTER EXTENSION UPDATE; fresh mode is a single CREATE EXTENSION)

[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: 1ad6baaa-63f4-4b98-a377-b2065605bdf2

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.}