Add full update+upgrade test harness (TEST_LOAD_SOURCE/TEST_SCHEMA, bin/test_existing, pg-upgrade-test/extension-update-test)

[jnasbyupgrade]

PR #11 built count_nulls' extension-update/pg_upgrade test harness against a
branch base that predates the stable-version flip (#13), RELEASE.md (#12),
pgxntool 2.2.0 (#17), and pg-tle-test (#16) - so it landed on the
pgxntool-update branch instead of master, and the two branches were
never reconciled. This forward-ports that work onto current master.

What changed, mechanically: test/deps.sql now installs the extension
fresh, via an in-place ALTER EXTENSION UPDATE from 0.9.6, or asserts it's
already installed (a real pg_upgrade/out-of-band update) - selected by the
TEST_LOAD_SOURCE GUC - and separately targets a schema (or none at all)
via TEST_SCHEMA, both propagated from the Makefile through PGOPTIONS.
bin/test_existing centralizes the install -> plant dependency guard ->
update/upgrade -> assert -> run-suite flow shared by two new CI jobs:
extension-update-test (ALTER EXTENSION UPDATE, no pg_upgrade) and
pg-upgrade-test (a real binary pg_upgrade across PostgreSQL majors). A
changes job derives the supported-PostgreSQL-major list once, gates all
four heavy jobs (including the existing pg-tle-test) on doc-only pushes,
and all-checks-passed gives branch protection one stable required check
name instead of per-matrix-cell ones.

Verified locally against this container's live PG17 (and confirmed PG12
availability for the CI matrix's older leg): make test, make test-update,
both crossed with TEST_SCHEMA=Quoted, plus a live
bin/test_existing update-scenario run (empty and Quoted schema) all pass,
including the dependency guard correctly blocking a non-CASCADE
DROP EXTENSION and the version check now correctly comparing against
stable rather than a stale numeric version. Did not run a real
pg_upgrade locally - this container's PG12/PG17 clusters are persistent
shared dev infrastructure, not disposable, so that leg is left for CI's
ephemeral containers to exercise first.

What this took from cat_tools (via pgxntool-update / PR #11), what changed, what's new

Taken essentially verbatim (already true of PR #11, carried forward
unchanged): the TEST_LOAD_SOURCE/TEST_SCHEMA GUC-propagation mechanism,
the dependency-guard technique (plant + actively prove a blocked
non-CASCADE drop, re-prove after every step), bin/test_existing's
subcommand structure, the changes job's docs-only gate and single-source
PG-major derivation, and the numbered-alternate-expected-file handling for
TEST_SCHEMA's three genuinely-different landing scenarios (documented in
test/README.md's scenario table, not just left as "these differ").
count_nulls needs no bridge-update leg and no omit_column fix - it has
always been pure SQL functions with no SELECT *-over-catalog views, so it
never accumulated the pg_upgrade-unsafe old versions those exist for.

Adapted, and worth flagging as the one real functional bug this forward-port
had to fix: bin/test_existing's version check compared against
print-PGXNVERSION (the PGXN distribution version). That was correct when
PR #11 was written, but master has since flipped default_version to the
literal stable pseudo-version (#13) - PGXNVERSION is still a real number
(currently 1.0.0), so every version assertion would have failed comparing
installed=stable against expected=1.0.0. Fixed to
print-EXTENSION_count_nulls_VERSION (the control file's actual
default_version), matching the same distinction the existing pg-tle-test
job already had to make for the same reason. Also added the second
DATA += sql/count_nulls--0.9.6.sql Makefile line alongside the existing
--1.0.0.sql one - master's stable-version work already worked around
pgxntool's DATA wildcard gap (Postgres-Extensions/pgxntool#48) for the
outgoing current version; the update tests need the same workaround for the
oldest version they install from.

Invented, not in PR #11 or cat_tools' own PR #16:
bin/compare_fresh_vs_update, wired into extension-update-test as an
automatic CI step. The doc this work is based on (§9) notes cat_tools found
a real update-script bug this way in PR #46 - a pre-0.2.2 update path left
EXECUTE PROCEDURE hardcoded where fresh installs already used
EXECUTE FUNCTION - but only as a manual, uncommitted, one-off diff. This
commits that technique as reusable tooling: it installs fresh and
0.9.6-then-updated copies in scratch databases and diffs
pg_get_functiondef/comments/ACLs for every object the extension owns
(discovered live via pg_depend, not a hardcoded object list), so it stays
correct if count_nulls grows new functions later. Ran clean both schema
legs locally - count_nulls' own update path has no such divergence today,
but the check itself is what's new, not the (currently negative) result.

Skipped, deliberately, not forgotten: centralizing the load-mode switch
into pgxntool's test/install/ (a single committed-once installer, per
cat_tools' test/install/load.sql) instead of count_nulls' current
per-test-file test/deps.sql. Already flagged as a TODO in
test/core/functions.sql - a real, independent argument regardless of this
PR, just out of scope for a forward-port. Also left the
every-major stepwise pg-upgrade-stepwise climb job unbuilt: count_nulls
has no catalog-touching views/functions, so the two big-jump pg-upgrade-test
legs already cover the risk that job exists for.

🤖 Generated with Claude Code

[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: 96b12edb-1ea3-403d-8b83-1de536c27a64

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

---

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

[jnasbyupgrade]

CI is fully green: all 51 checks passed, including the real binary pg_upgrade legs (10→18, 12→18, both schema legs) that couldn't be verified locally in this dev container (its PG12/PG17 clusters are persistent shared infra, not disposable, so I deliberately left that leg for CI's ephemeral containers rather than risk them).

[jnasbyupgrade]

Superseded by a phased stacked-PR redesign that adopts pgxntool's test/install feature to decouple installation from the main suite (per pgxntool/README.asc's own U&U documentation, which this PR's approach didn't follow), avoiding the numbered-alternate-expected-file approach here. Keeping the branch around for salvage (CI job shapes, guard SQL, compare_fresh_vs_update).