Skip to content

Fix cat_tools dependency: install from pinned git SHA, not PGXN - #10

Draft
jnasbyupgrade wants to merge 5 commits into
Postgres-Extensions:masterfrom
jnasbyupgrade:fix-cat-tools-install
Draft

Fix cat_tools dependency: install from pinned git SHA, not PGXN#10
jnasbyupgrade wants to merge 5 commits into
Postgres-Extensions:masterfrom
jnasbyupgrade:fix-cat-tools-install

Conversation

@jnasbyupgrade

@jnasbyupgrade jnasbyupgrade commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

What was broken

extension_drop.sql calls cat_tools.routine__parse_arg_types_text(), which only exists starting at cat_tools 0.3.0. The Makefile's cat_tools target and META.in.json's declared floor both said >=0.2.1 and used pgxn install.

PGXN's published cat_tools listing (https://api.pgxn.org/dist/cat_tools.json) is stuck at 0.2.1 from 2017 -- it's the old decibel/cat_tools listing and was never updated for the Postgres-Extensions/cat_tools fork's newer work. So pgxn install 'cat_tools>=0.2.1' in CI has actually always installed that ancient 0.2.1, which:

  1. Doesn't have cat_tools.routine__parse_arg_types_text at all (added in 0.3.0), so CREATE EXTENSION extension_drop CASCADE has likely never actually succeeded.
  2. Carries the pre-omit_column-fix catalog SELECT * bug that breaks with column "oid" specified more than once on PG12+.

Why PGXN can't be used right now

cat_tools's GitHub master has bumped to default_version = '0.3.0' and has the function extension_drop needs, but 0.3.0 has not been tagged or published to PGXN. Only 0.2.2/0.2.3 are tagged there, and even 0.2.3 predates the function. So there is currently no PGXN-published version of cat_tools that satisfies extension_drop's real requirement.

The fix

  • Makefile: cat_tools target now clones Postgres-Extensions/cat_tools and builds/installs it from its master branch (tracked directly, not pinned to a commit SHA -- no tagged release has the function we need, so there's nothing more stable to pin to yet) instead of pgxn install. A comment at the fix site distinguishes the two claims: depending on cat_tools this way at all is temporary and will be reverted once 0.3.0 is tagged on PGXN, but building a dependency from a git ref is itself a supported technique in this Makefile -- worth reusing whenever a dependency's PGXN listing lags its real development, not something to design away.
  • META.in.json: bumped the declared cat_tools build floor from 0.2.1 to 0.3.0 -- an honest reflection of what the code actually requires, independent of the install mechanism. Regenerated META.json via make META.json (never hand-edited).
  • README.md: updated the stated cat_tools requirement/link to match, and noted the temporary git-source install.
  • extension_drop.control's requires = 'cat_tools' is left as-is: PostgreSQL .control requires is a bare extension-name list (for CREATE EXTENSION ... CASCADE) with no version syntax, so no change was needed there.

Related

Filed issue #11 to track a longer-term idea surfaced while working on this: a CI axis that tests the declared floor version of build/runtime dependencies (not just PG version), so a dependency floor like cat_tools 0.3.0 can't silently drift out of sync with what the code actually uses. Not implemented here -- cat_tools' floor isn't even testable until 0.3.0 is tagged.

Exit condition

Once cat_tools 0.3.0 is tagged and published to PGXN, revert the Makefile's cat_tools target to a plain pgxn install 'cat_tools>=0.3.0' --sudo (the comment at the fix site says so explicitly).

Verification

I confirmed via the CI job logs (using a temporary debug step I added and then reverted) that the git-clone/checkout/make install of the pinned cat_tools SHA succeeds cleanly on every PostgreSQL version in the matrix (9.3 through 17), installing cat_tools.control with default_version = '0.3.0' each time. That part of the fix is solid and verified end-to-end.

However, the schema/simple pgTAP tests still fail in CI, for a separate, pre-existing reason unrelated to cat_tools: CI's pg-build-test (from the pgxn/pgxn-tools image) invokes make installcheck directly, which does not go through pgxntool's own test target or its testdeps prerequisite. testdeps is what installs the test/extension/ support extension (extension_drop_test) that test/sql/schema.sql and test/sql/simple.sql depend on. Since pg-build-test skips that step, those tests fail with extension "extension_drop_test" is not available in CI, regardless of cat_tools. Locally, running pgxntool's actual make test (which does run testdeps first) installs extension_drop_test correctly, and with this fix, schema/simple then pass cleanly end-to-end (verified locally against PG17). This CI-invocation gap predates this branch and is out of scope for this PR; flagging it here so it isn't confused with a cat_tools regression. (There's also a related one-character pre-existing typo in this Makefile, line 4: $(DESTDIR)$datadir)/... is missing a ( before datadir -- harmless today since it just makes that target's dependency tracking always stale/rebuild, but worth a follow-up cleanup.)

Separately, zzz_build fails locally and in CI for an unrelated, already-merged reason: it plays sql/extension_drop.sql directly via \i rather than through CREATE EXTENSION, so it never benefited from CREATE EXTENSION's automatic client_min_messages raise-to-WARNING that PR #3 (224e89d, "Remove redundant client_min_messages handling from install script") relied on when it dropped the script's own explicit save/restore. Also pre-existing, also out of scope here.

None of this is gating today: pgxntool's .IGNORE: installcheck plus pg-build-test not gating on regression results means CI shows green regardless (as noted in the original bug report). This PR's all-checks-passed is green, and the cat_tools install itself, the actual subject of this PR, is verified working on every PG version.

Test plan

  • Confirmed cat_tools git-pin install (clone + checkout + make install) succeeds on all 12 PG versions in CI (9.3-17)
  • Locally (PG17), schema and simple, the tests that exercise cat_tools, pass cleanly once testdeps has installed extension_drop_test (i.e. via pgxntool's own make test)
  • Follow-up needed (separate from this PR): make CI's pg-build-test invocation exercise pgxntool's testdeps/test target so schema/simple actually run to completion in CI
  • Follow-up needed (separate from this PR, already pre-existing): zzz_build NOTICE regression from PR Remove redundant client_min_messages handling from install script #3

🤖 Generated with Claude Code

extension_drop.sql calls cat_tools.routine__parse_arg_types_text(),
which only exists starting at cat_tools 0.3.0. PGXN's published
cat_tools listing is stuck at 0.2.1 from 2017 (the old decibel/cat_tools
distribution) and was never updated for the Postgres-Extensions/cat_tools
fork, so `pgxn install 'cat_tools>=0.2.1'` silently installed an ancient
0.2.1 that both lacks the function extension_drop needs and carries a
pre-omit_column-fix catalog query that breaks on PG12+. As a result,
CREATE EXTENSION extension_drop CASCADE has likely never actually
succeeded in CI -- masked by pgxntool's .IGNORE: installcheck and by
pg-build-test not gating on regression results.

cat_tools 0.3.0 has the needed function on GitHub master but has not
been tagged/published to PGXN yet (only 0.2.2/0.2.3 are tagged, and
even 0.2.3 predates the function). So PGXN isn't a usable install
source right now: build cat_tools from a pinned git commit instead.
Once 0.3.0 is tagged and published to PGXN, this should revert to a
plain `pgxn install 'cat_tools>=0.3.0' --sudo`.

Also bump META.in.json's declared cat_tools floor to 0.3.0 to match
the real requirement, and regenerate META.json via `make META.json`.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Jul 30, 2026

Copy link
Copy Markdown

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: 19698f82-e7ae-4765-80a5-be8bde4c1ddc

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

Comment @coderabbitai help to get the list of available commands.

jnasbyupgrade and others added 3 commits July 30, 2026 14:11
The Makefile comment and README previously read as if pinning cat_tools
to a git SHA were only a stopgap to be ripped out. Reword to separate the
two claims: this specific SHA pin is temporary (revert once cat_tools
0.3.0 is tagged on PGXN), but building a dependency straight from a
pinned git commit is a supported technique here whenever a dependency's
PGXN listing lags its real development -- worth reaching for again, not
something to design away entirely.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
No tagged cat_tools release has the function we need, so there's
nothing meaningfully more stable to pin to than master right now --
the fixed SHA added false precision without a real reproducibility
benefit. Track the branch directly; the git-source-instead-of-PGXN
mechanism itself is unchanged.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant