Sync pgxntool to 2.3.0

[jnasbyupgrade]

Pulls the latest pgxntool release (2.3.0, up from 2.2.0) via git subtree pull. This release fixes both issues filed from our 2.2.0 sync: #78 (PGTLE_VERSION collision, renamed upstream to PGXNTOOL_PGTLE_VERSION) and #79 (check-stale-expected running before install, fixed by making installcheck unconditionally depend on install in base.mk).

That #79 fix reintroduces the exact problem bin/test_existing's TEST_EXISTING_DEPLOY=pgtle mode exists to avoid: calling installcheck directly now also runs install, writing cat_tools.control to the real extension directory even though the database under test was deployed via pg_tle -- tripping bin/assert_fs_clean. Since pgxntool no longer offers a way to skip install (that's a separate, still-open request, pgxntool#55), this redirects install's filesystem writes to a throwaway DESTDIR instead: existing mode's suite never exercises install's output (the extension is already present via pg_tle), so where it writes doesn't matter as long as it isn't the real extension directory. Verified locally against a real database: the real extension directory's cat_tools files are byte-for-byte unchanged (by checksum) after a full TEST_EXISTING_DEPLOY=pgtle run-suite invocation, and all 14 tests still pass.

No other cat_tools-side changes were needed for this sync -- EXTENSION_VERSION_FILES/PGTLE_VERSION aren't referenced anywhere in our own Makefile/sql.mk beyond what 2.2.0 already required. A few workarounds in our code are now redundant given what 2.3.0 fixes upstream; those are being cleaned up separately rather than bundled into this sync.

[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: f84000c1-9842-4efa-8ce2-67c03edb40c3

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

[github-actions]

Code review

3 issues found. (Note: inline line comments were not available in this environment, so findings are consolidated here with direct links to the relevant lines.)

1. DESTDIR redirect reintroduces a real, live pgtap install (significant)

cat_tools/bin/test_existing

Lines 258 to 265 in 304b4f3

	local pgtle_destdir
	pgtle_destdir=$(mktemp -d)
	make testdeps $existing_args
	make installcheck $existing_args DESTDIR="$pgtle_destdir"
	local testout
	testout=$(make -s print-TESTOUT 2>/dev/null | sed -n 's/.*set to "\(.*\)"$/\1/p')
	pgxntool/verify-results-pgtap.sh "$testout"
	rm -rf "$pgtle_destdir"

The new DESTDIR="$pgtle_destdir" override on make installcheck does not achieve the filesystem isolation it is meant to provide. pgxntool/base.mk (untouched by this PR) has:

installcheck: pgtap
pgtap: $(DESTDIR)$(datadir)/extension/pgtap.control

$(DESTDIR)$(datadir)/extension/pgtap.control:
	pgxn install pgtap --sudo

installcheck depends on pgtap, whose prerequisite path incorporates DESTDIR, but the recipe itself (pgxn install pgtap --sudo) never reads DESTDIR -- it always installs into the real system extension directory. Since $pgtle_destdir is a fresh, empty mktemp -d directory, $(DESTDIR)$(datadir)/extension/pgtap.control can never exist there, so Make concludes pgtap is stale and runs pgxn install pgtap --sudo for real -- hitting sudo/network and writing to the actual system extension directory on every pg_tle-mode run. .github/workflows/ci.yml already documents this exact failure mode (confirmed happening in a real CI run) for the pg_tle jobs, which is why they pre-install pgtap via a dedicated make pgtap step before the baseline filesystem snapshot. This likely will not turn the job red (the reinstalled content matches what CI already installed), but the isolation this new comment block claims (a scratch DESTDIR keeps the real extension directory untouched) does not actually hold for the pgtap prerequisite.

Possible fix: seed $pgtle_destdir with a stub pgtap.control before the make installcheck call, or otherwise keep the pgtap prerequisite off the overridden DESTDIR.

2. Bare issue reference violates CLAUDE.md

cat_tools/bin/test_existing

Lines 39 to 43 in 304b4f3

	# under test was deployed via pg_tle, not the filesystem, and must NEVER be
	# filesystem-installed by anything this script does. pgxntool 2.3.0 fixed
	# installcheck running before install (issue #79) by making `installcheck`
	# itself unconditionally depend on `install` in base.mk -- so even calling
	# `installcheck` directly (bypassing `test`) now runs `install` too, with no

Line 41 reads (issue #79) -- a bare issue number. Per this repos CLAUDE.md rule on PR/issue references, references inside committed files must be full URLs, never a bare #NN. bin/test_existing is cat_tools own authored file (not vendored pgxntool content), so the rule applies. Full URLs are used correctly elsewhere in this same comment block (lines 51 and 256), so this looks like an oversight rather than a deliberate choice.

Suggested fix: change (issue #79) to (https://github.com/Postgres-Extensions/pgxntool/issues/79).

3. Scratch DESTDIR leaks on the failure path (minor)

cat_tools/bin/test_existing

Lines 258 to 265 in 304b4f3

	local pgtle_destdir
	pgtle_destdir=$(mktemp -d)
	make testdeps $existing_args
	make installcheck $existing_args DESTDIR="$pgtle_destdir"
	local testout
	testout=$(make -s print-TESTOUT 2>/dev/null | sed -n 's/.*set to "\(.*\)"$/\1/p')
	pgxntool/verify-results-pgtap.sh "$testout"
	rm -rf "$pgtle_destdir"

$pgtle_destdir is only cleaned up by the plain rm -rf at the end of this block. The script runs under set -euo pipefail (line 69), and this is exactly the path where make installcheck / verify-results-pgtap.sh exit non-zero on genuine test failures -- a routine outcome here, not a contrived edge case. Any failure between mktemp -d and the final rm -rf aborts the script before cleanup runs, leaking the temp dir (a full scratch extension install tree). Low impact since this runs in ephemeral CI containers, but also affects local developer runs against a scratch DB.

Suggested fix: add a trap right after mktemp -d, e.g. trap 'rm -rf "$pgtle_destdir"' EXIT (use EXIT, not RETURN -- under errexit the script exits directly rather than returning from the function normally, so a RETURN trap would not fire here), and drop the now-redundant trailing rm -rf.