ci: pg_tle deployment smoke test for extension_drop (chained on cat_tools)

[jnasbyupgrade]

Migrated from fork-internal PR jnasbyupgrade#5 to enable a native same-repo stacked PR (bases off test-install-foundation, which now exists directly on Postgres-Extensions/extension_tools). Original PR: jnasbyupgrade#5

---

Summary

Adds a pg-tle-test CI job that proves extension_drop can be deployed with
zero filesystem footprint, via pg_tle (AWS's Trusted Language Extensions
— a database-backed catalog for installing an extension with no .control
file on disk; relevant for RDS/Aurora-style managed deployments). This is a
third deployment dimension, orthogonal to the fresh/update/existing testing
this stack already added in test-install-foundation — not how the
extension got there across time, but filesystem-installed vs. registered
purely through pg_tle's catalog.

This branch stacks on:

• test-install-foundation (fork-internal, this PR's base) — test/install/load.sql, TEST_LOAD_SOURCE, the dependency guard
• fix-cat-tools-install (upstream draft Postgres-Extensions/extension_tools#10, transitively) — cat_tools installed from a pinned git ref because PGXN's published listing is a stale 2017 release

The chained-dependency gap this fills

The reference implementation for pg_tle testing is Postgres-Extensions/cat_tools PR #47's pg-tle-test job — read directly from cat_tools's current ci.yml, not just summarized. cat_tools is a leaf extension (no dependencies of its own), so its job never had to solve registering a chained dependency through pg_tle. extension_drop requires cat_tools (.control's requires = 'cat_tools', and its own SQL calls cat_tools.routine__parse_arg_types_text(...)), so CREATE EXTENSION extension_drop CASCADE only resolves cleanly if cat_tools is also already registered as a pg_tle extension — otherwise the CASCADE either fails outright or (worse) silently resolves cat_tools from a stray filesystem install, defeating the whole point of the test. This job registers, in order: pg_tle → cat_tools (cloned fresh at the same CAT_TOOLS_GIT_REF the Makefile's own filesystem cat_tools target pins to, read via make print-CAT_TOOLS_GIT_REF so the two never drift) → extension_drop (this repo's own make run-pgtle) — all against template1, before any database that needs them is created.

What's taken from cat_tools verbatim / adapted / skipped

• Verbatim in spirit, adapted in detail: bin/assert_fs_clean (snapshot/verify subcommands, diffing *.control files against a pre-pg_tle baseline) is modeled directly on cat_tools' script of the same name — same mechanism, same reasoning (a stray filesystem control file silently wins over a pg_tle registration of the same name; PostgreSQL never errors, it just resolves from disk). Comments rewritten to stand on their own rather than referencing cat_tools.
• Adapted: the job structure (dedicated cluster, snapshot-before-pg_tle-install, register-against-template1, fs-clean checks bracketing every step) follows cat_tools' pg-tle-test job shape. The registration step is the real addition — cat_tools' equivalent step is a single make run-pgtle; this repo's is three ordered registrations (pg_tle, cat_tools, extension_drop) because of the dependency chain.
• Skipped for now (noted so it isn't mistaken for an oversight):
  • The update path via pg_tle (cat_tools' job also tests ALTER EXTENSION UPDATE through pg_tle). extension_drop has no prior released version to update from yet — TEST_UPDATE_FROM has no safe default (see the Makefile's own comment) — so there's nothing real to exercise. Straightforward to add once a real second version ships.
  • Binary pg_upgrade of a pg_tle-deployed extension (cat_tools' pg-tle-upgrade-test). A separate, heavier concern from a fresh-install smoke test.
  • A workflow-level concurrency: group. test-fixes.md-style guidance recommends one, and this workflow doesn't have one yet, but a sibling fork branch (pg-upgrade-ci, same base) is concurrently adding its own job to this same ci.yml — to keep this PR a small, low-conflict diff I deliberately limited my changes to adding my own job plus wiring it into all-checks-passed's needs: list, rather than also touching shared workflow-level YAML. Worth adding in a follow-up once both stacks have landed.
  • No new changes/docs-only gate job — this repo doesn't have one yet; out of scope here.

PG version matrix

Intersection of two independently-moving ranges, checked directly rather than assumed: extension_drop's own tested range (test job: 9.3–17) and pg_tle 1.5.2's supported PostgreSQL range (12–18, dropped PG11 — see pgxntool/pgtle_versions.md). Matrix is [12, 13, 14, 15, 16, 17] — 18 is left out since the existing test job doesn't cover it either.

Local verification

Rehearsed the full flow end to end in this dev container (PG17, on a dedicated throwaway cluster created specifically for this — never touching the shared main/pgupgradetest clusters other work in this container uses):

1. Built pg_tle 1.5.2 from source against PG17, enabled shared_preload_libraries.
2. CREATE EXTENSION pg_tle on template1; registered cat_tools (cloned at master, the current CAT_TOOLS_GIT_REF) via make run-pgtle, then this repo's own extension_drop via make run-pgtle — both against template1.
3. createdb + CREATE EXTENSION extension_drop CASCADE — succeeded, with NOTICE: installing required extension "cat_tools" confirming CASCADE resolved the dependency through pg_tle.
4. Asserted extversion matched make print-PGXNVERSION (1.0.0) dynamically, and called extension_drop__add/__get/__remove against a real installed extension (pg_tle itself) — a real function call, not just a successful install.
5. Confirmed zero filesystem .control files present throughout via bin/assert_fs_clean (this dev container actually already had stale filesystem installs of both cat_tools and extension_drop from earlier work in this repo, which — usefully — surfaced a real thing worth knowing: pg_tle's own pgtle.install_extension refuses to register over a pre-existing filesystem control file of the same name, raising control file already exists for the ... extension. I briefly relocated just those two extensions' specific files to rehearse a clean registration, then restored them and confirmed via bin/assert_fs_clean diff that the filesystem was back to its exact prior state, modulo the expected new pg_tle.control from this rehearsal.)
6. Also regression-tested bin/assert_fs_clean itself: confirmed it passes clean, fails when a synthetic stray .control file is injected, and passes again once removed.
7. Caught and fixed a real bug during this process: the registration step's cd cat_tools_clone && git checkout ... would have persisted for the rest of that run: block (one continuous shell script), making the following make run-pgtle (meant for this repo) run inside the cat_tools clone instead. Fixed by using -C on both git and make rather than a bare cd.

CI itself will be the final confirmation on a genuinely clean runner (no pre-existing filesystem installs to work around, unlike this dev container).

Test plan

• pg-tle-test matrix (PG 12–17) goes green on this PR
• all-checks-passed reflects the new job in its needs: list
• Confirm no odd CI-triggering behavior from the multi-level fork-internal stack (base is test-install-foundation, itself based on the upstream draft fix-cat-tools-install)

🤖 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: dad5f84f-d3be-4741-b2af-927ce0c16eb0

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