Extend pg-tle-test to cover the update path

[jnasbyupgrade]

PR #23 (add-update-upgrade-testing) built the extension-update/pg_upgrade
test harness (bin/test_existing, TEST_LOAD_SOURCE/TEST_SCHEMA, the
extension-update-test and pg-upgrade-test CI jobs) and, separately, an
earlier pg-tle-test job (#16) proved count_nulls installs and works when
registered through AWS pg_tle's database-backed catalog instead of a
filesystem .control file - but only for a FRESH install. This PR closes that
gap: pg-tle-test now also exercises the 0.9.6 -> current update path through
pg_tle, not just a fresh install.

Stacks on #23 (base branch add-update-upgrade-testing, not master) since it
needs bin/test_existing, which only exists there. Should be rebased onto
master once #23 merges.

What's new here vs. #23: a second scratch database, created after the
existing job's template1 pg_tle registration (so it inherits it too,
same reasoning as the existing fresh-install smoke-test db) - installs
count_nulls at 0.9.6, ALTER EXTENSION UPDATEs it to current, and runs the
pgTAP suite against it in existing mode (bin/test_existing's
update-scenario subcommand, unmodified - it's already pg_tle-transparent
once the target database descends from the pg_tle-registered template1).
Bracketed with the same bin/assert_fs_clean verify calls as every other
step in this job, so the whole update-path run is proven to never write a
filesystem control file either.

The one piece of new plumbing needed in bin/test_existing itself:
run_suite() unconditionally called make test / make verify-results, and
pgxntool's test target unconditionally depends on install (a real
filesystem install) - reusing run_suite as-is here would have silently
filesystem-installed count_nulls, defeating the entire point of proving
pg_tle-only deployment. Added a TEST_EXISTING_DEPLOY=pgtle environment
switch, read only by run_suite: in that mode it calls make testdeps +
make installcheck directly instead (verified against pgxntool/base.mk that
neither depends on install - only test does, via
TEST_DEPS += install installcheck), then runs
pgxntool/verify-results-pgtap.sh directly against the results - the same
pass/fail check make verify-results runs, but the script itself only
takes TESTOUT as an argument and has no dependency on the test target, so
calling it directly gets the same logic without going through the
test-target dependency chain. Everything else in bin/test_existing (create
at 0.9.6, plant/prove the guard, ALTER EXTENSION UPDATE) needed no changes.

Validated locally on this container's live PG17 cluster (no local pg_tle
install attempted - modifying this shared cluster's
shared_preload_libraries felt too risky with other sessions potentially
running in parallel, so this substituted a real filesystem-installed
count_nulls as a stand-in for pg_tle to validate the TEST_EXISTING_DEPLOY
plumbing itself): confirmed TEST_EXISTING_DEPLOY=pgtle bin/test_existing update-scenario ... 0.9.6 runs the full update-scenario flow (guard
planted and proven, ALTER EXTENSION UPDATE, pgTAP suite passing in existing
mode) end to end, and - checking count_nulls.control's mtime before/after -
confirmed the pgtle-mode call never re-triggers install, while the
default (unset TEST_EXISTING_DEPLOY) mode still does, as expected. The real
pg_tle-registered version of this will need a genuine CI run to confirm.

Bug found from real CI, not caught locally: the update-path leg above failed
on its first real CI run. test/deps.sql's existing-mode assertion compares
pg_extension.extversion against pg_available_extensions.default_version, but
pg_available_extensions only ever reads .control files directly off disk -
it has no knowledge of pg_tle's separate, database-backed registration
catalog. Under this job's pg_tle-only deployment, default_version came back
NULL even though the earlier fresh-install smoke test in the SAME job proves
a version-less CREATE EXTENSION correctly resolves the current version
through pg_tle - that smoke test just never happens to touch
pg_available_extensions itself, only pg_extension.extversion, so this is the
first time this particular cross-check has ever run against a real
pg_tle-registered database. Confirmed against pg_tle's own tleextension.c
(v1.5.2, aws/pg_tle): pg_available_extensions is only ever described there as
modeled on pgtle.available_extensions() ("The system view
pg_available_extensions provides a user interface to this SRF") - pg_tle
never hooks or populates the real view, it only ships its own separate,
non-integrated analog function in the pgtle schema.

Fixed by adding a TEST_EXISTING_DEPLOY-driven GUC
(count_nulls.test_existing_deploy, default 'filesystem', reusing the env var
name bin/test_existing already reads) so test/deps.sql's existing-mode
cross-check picks the right source: pg_available_extensions for filesystem
installs (unchanged, still exactly as strict as before) or
pgtle.available_extensions() when TEST_EXISTING_DEPLOY=pgtle. Verified
locally against both branches with a stub pgtle.available_extensions()
function (real pg_tle isn't installed in this container): matching version
passes, a NULL/mismatched version still fails loudly, and the filesystem
branch is untouched.

🤖 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: 227f32f4-73b6-4d76-91d4-0b688b420270

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]

Stacked on #23, so closing alongside it. The pg_tle/pg_available_extensions bug found here is real and will be ported forward into the new design's pg_tle phase.