Makefile: cat_tools install override (CAT_TOOLS_GIT_REF/CAT_TOOLS_SKIP_INSTALL), default unchanged

[jnasbyupgrade]

Redesigned. The original version unconditionally replaced the Makefile's
default cat_tools install (plain pgxn install) with a git-source build,
for every consumer of this repo -- not just CI. That's wrong: PGXN's stale
listing is CI's/testing's problem to work around, not something that should
change the default make install/pgxn install behavior everyone else gets.

What this PR actually does now

Reverts the default cat_tools recipe to exactly what it was
(pgxn install 'cat_tools>=0.2.1' --sudo), and adds two empty-by-default
variables as an explicit, opt-in override:

• CAT_TOOLS_GIT_REF: when set, installs cat_tools from that git ref
  instead of PGXN.
• CAT_TOOLS_SKIP_INSTALL: when set, skips installing cat_tools entirely
  (for pg_tle-mode testing, where cat_tools is already provided via pg_tle
  registration and a filesystem install as a side effect would defeat the
  point of the test).

Neither variable changes anything for a caller that doesn't set them --
make/make install/pgxn install extension_drop behave identically to
before this PR.

No version/META changes here. Bumping the declared cat_tools floor and
actually wiring CI to use CAT_TOOLS_GIT_REF is a separate concern, handled
in the version-pin PR (#25) stacked on this one -- keeping "add the override
mechanism" and "decide which version to use" as independent, separately
reviewable changes.

Verified locally (PG17)

• Default (no vars set): pgxn install 'cat_tools>=0.2.1' --sudo runs,
  installs 0.2.1, exactly as before.
• CAT_TOOLS_GIT_REF=0.3.0: clones and builds cat_tools at the 0.3.0 tag,
  installs correctly, cleans up its build dir afterward.
• CAT_TOOLS_SKIP_INSTALL=yes: true no-op, confirmed nothing gets installed.
• Confirmed make -n cat_tools is genuinely dry (prints without executing)
  in all three cases -- an earlier draft of this recipe accidentally forced
  real execution under -n by referencing $(MAKE) (GNU Make always runs
  recipes containing that literal text, even under -n, so it can show what
  a sub-make would do) and separately had a cd $(CAT_TOOLS_BUILD_DIR) &&
  that persisted across the whole joined shell recipe, breaking a later -C
  reference to the same relative path. Fixed by using plain make (not
  $(MAKE)) for the nested build and git -C <dir> instead of cd &&.

[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: 0e375649-0cdb-4795-86f9-4362e81421c4

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]

Claude Code is working…

I'll analyze this and get back to you.

View job run

[github-actions]

Claude finished @jnasbyupgrade's task in 2m 55s —— View job

---

Claude finished reviewing PR #10

• Gather context (diff, changed files, CLAUDE.md)
• Review Makefile changes (cat_tools git-source build)
• Review META.in.json / META.json version bump
• Review README.md / RELEASE.md changes
• Review bin/in_release helper
• Post final review

Summary

Solid, well-documented fix. The root cause analysis (PGXN's cat_tools listing being stuck at a 9-year-old 0.2.1) is correct and thoroughly verified per the PR description (12 PG versions in CI). One process gap worth fixing before merge, plus a couple of minor/optional notes.

Findings

1. Missing HISTORY.asc entry (should fix)

RELEASE.md's own "Ongoing development" section (pre-existing, not touched by this PR) requires:

If a PR makes a user-facing change (bug fix, behavior change...), add an entry to HISTORY.asc... If the top section is a real version number, insert a new section above it headed STABLE.

HISTORY.asc's top heading is currently 1.0.0 (a real released version, confirmed via bin/in_release's own logic — no STABLE section exists yet). This PR is squarely a user-facing bug fix (per its own description, CREATE EXTENSION extension_drop CASCADE "has likely never actually succeeded" without it), but it doesn't touch HISTORY.asc. Per the project's documented convention, it should insert a new STABLE section above 1.0.0 describing the fix.

Fix this →

2. git clone is a full clone of master (minor/optional)

Makefile line 41 does a full git clone then git checkout $(CAT_TOOLS_GIT_REF) (line 42), where CAT_TOOLS_GIT_REF = master. Since the ref is a branch name (not yet pinned to a SHA), git clone --branch master --depth 1 ... would be faster and lighter in CI, with the explicit git checkout still there ready to take a SHA once/if this needs pinning later. Not a correctness issue — just an optimization opportunity, and worth leaving as full-clone if you want the checkout line to already look correct for a future SHA pin without editing the clone line too.

3. No protection against upstream master drift between CI runs (acknowledged risk)

Because CAT_TOOLS_GIT_REF tracks a moving branch rather than a SHA, two CI runs at different times could build against different cat_tools commits, so a future breaking change on cat_tools upstream could break this repo's CI without any change here. This is explicitly called out as an accepted, temporary tradeoff in the PR description and Makefile comment (no tagged release exists yet to pin to), so it's not blocking — just flagging that it's a real (if intentional) gap, not purely theoretical.

Nice-to-haves already handled well

• META.in.json/META.json bump is consistent and META.json was correctly regenerated rather than hand-edited.
• extension_drop.control's bare requires = 'cat_tools' correctly left untouched (PostgreSQL .control requires has no version syntax).
• The new RELEASE.md "never release with a pin" callout and bin/in_release helper are a good, low-cost safety net for a real footgun this PR introduces (a temporarily unpinnable dependency floor).
• Comments in the Makefile clearly separate the durable technique (build-from-git-ref as a supported fallback) from the temporary state (tracking master because no tag exists), which will make the eventual revert straightforward.

Not addressed by this PR (correctly out of scope, per the PR description)

• CI's pg-build-test skipping pgxntool's testdeps step, causing schema/simple pgTAP tests to fail in CI for unrelated reasons.
• The pre-existing Makefile line 4 typo ($(DESTDIR)$datadir)/... missing a ().
• zzz_build's pre-existing NOTICE-handling regression from PR Remove redundant client_min_messages handling from install script #3.

These are all called out explicitly in the PR body and tracked/flagged appropriately rather than silently ignored.

[github-actions]

Claude finished @jnasbyupgrade's task in 3m 39s —— View job

---

Claude finished reviewing PR #10

• Gather context (diff, changed files, CLAUDE.md)
• Review Makefile changes (cat_tools install override)
• Cross-check CI workflow wiring
• Post final review

Summary

Note up front: the PR description/title above describe an earlier version of this PR (git-source build by default, META.in.json/README.md/RELEASE.md/bin/in_release changes). The branch has since been redesigned — the current diff is a single commit, ef2e29d ("Makefile: cat_tools install override, default behavior unchanged"), touching only Makefile (+25/-1). This review is against that current diff, not the stale description text.

The redesign is a real improvement over the previous approach: it makes the git-source build strictly opt-in via CAT_TOOLS_GIT_REF/CAT_TOOLS_SKIP_INSTALL, so every other consumer of this Makefile still gets the original pgxn install 'cat_tools>=0.2.1' --sudo behavior untouched. That's a good, low-blast-radius design. Two issues below are worth resolving before merge.

Findings

1. The new opt-in vars aren't set anywhere, so this PR alone doesn't fix the underlying bug (should confirm)

Makefile:24-25 adds CAT_TOOLS_GIT_REF ?= and CAT_TOOLS_SKIP_INSTALL ?=, both empty by default, with the commit message stating "CI sets this, nothing else does." But .github/workflows/ci.yml's test job (pg-build-test) isn't touched by this PR and doesn't set CAT_TOOLS_GIT_REF anywhere. That means the cat_tools recipe (Makefile:30-41) will still fall through to the else branch — the plain pgxn install 'cat_tools>=0.2.1' --sudo — exactly as before. Since PGXN's published cat_tools listing is still stuck at 0.2.1 (missing routine__parse_arg_types_text, per this PR's own rationale), sql/extension_drop.sql:38's call to that function will still fail to resolve, and CREATE EXTENSION extension_drop CASCADE will still be broken in CI after this merges — unless a companion PR (updating ci.yml to pass CAT_TOOLS_GIT_REF=master or similar) lands alongside it.

If that wiring is intentionally deferred to a separate PR, worth saying so explicitly in the PR description so reviewers don't assume this one is a complete fix on its own. If it isn't planned elsewhere yet, ci.yml needs a CAT_TOOLS_GIT_REF (or make variable passthrough) added for test's pg-build-test step.

Fix this →

2. Git-source install path is missing --sudo, unlike the PGXN path it replaces (should confirm)

Makefile:40 (pgxn install 'cat_tools>=0.2.1' --sudo) explicitly needs --sudo to write into $(DESTDIR)$(datadir)/extension. That requirement exists precisely because the pgxn-tools CI container's default user can't write there directly (see pgxntool/HISTORY.asc's "Use --sudo option when installing pgtap" entry, and pgxntool/base.mk:686's own pgxn install pgtap --sudo). The new git-source branch at Makefile:37 runs make -C $(CAT_TOOLS_BUILD_DIR) install PG_CONFIG=$(PG_CONFIG) DESTDIR=$(DESTDIR) with no privilege escalation at all. If the same directory-permission constraint applies (likely, since it's the same target directory), this will fail with a permission error the first time CAT_TOOLS_GIT_REF is actually exercised — e.g. once finding #1 above is wired up. Worth prefixing with sudo (or confirming the container's ownership model makes it unnecessary before relying on this path in CI).

Fix this →

Nice-to-haves already handled well

• Scoping the override behind empty-by-default CAT_TOOLS_GIT_REF/CAT_TOOLS_SKIP_INSTALL variables (Makefile:14-26) rather than changing the default recipe is the right call — every other consumer of this Makefile is unaffected.
• CAT_TOOLS_SKIP_INSTALL cleanly supports the pg_tle testing mode (where cat_tools is registered a different way) without forcing a filesystem install as a side effect.
• Build dir cleanup (rm -rf before and after the clone) avoids leaving stale checkouts around, and tmp/ is already gitignored.
• Deferring the META.in.json/version-floor bump to a separate PR (per the commit message) is a reasonable scope cut — this commit is purely mechanism, not policy.

Not addressed by this PR (pre-existing, out of scope)

• Makefile:4's pre-existing typo ($(DESTDIR)$datadir)/extension/extension_drop_test.control missing a ( before datadir) — unrelated to this diff, untouched here.