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

META.in.json

@@ -73,13 +73,13 @@
     "X_comment": "Valid keys for 'prereqs' are configure, build, runtime, or test.",
     "X_comment": "Valid keys for 'requires' are requires, recommends, suggests, or conflicts.",
     "X_comment": "Requires event_triggers, introduced in 9.3",
-    "X_comment": "cat_tools: requires extension support, added in 0.2.1",
+    "X_comment": "cat_tools: requires cat_tools.routine__parse_arg_types_text, added in 0.3.0",
     "prereqs": {
 
         "build": {
             "requires": {
                 "PostgreSQL": "9.3.0",
-                "cat_tools": "0.2.1"
+                "cat_tools": "0.3.0"
             }
         },
         "runtime": {

META.json

@@ -73,13 +73,13 @@
     "X_comment": "Valid keys for 'prereqs' are configure, build, runtime, or test.",
     "X_comment": "Valid keys for 'requires' are requires, recommends, suggests, or conflicts.",
     "X_comment": "Requires event_triggers, introduced in 9.3",
-    "X_comment": "cat_tools: requires extension support, added in 0.2.1",
+    "X_comment": "cat_tools: requires cat_tools.routine__parse_arg_types_text, added in 0.3.0",
     "prereqs": {
 
         "build": {
             "requires": {
                 "PostgreSQL": "9.3.0",
-                "cat_tools": "0.2.1"
+                "cat_tools": "0.3.0"
             }
         },
         "runtime": {

Makefile

@@ -11,7 +11,34 @@ $(DESTDIR)$datadir)/extension/extension_drop_test.control:
 deps: cat_tools
 install: deps
 
+# 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; `pgxn install
+# cat_tools` therefore installs an ancient 0.2.1 lacking the function we need
+# (and carrying a pre-omit_column-fix catalog query that breaks on PG12+).
+# 0.3.0 itself has not been tagged/published to PGXN yet -- only 0.2.2/0.2.3
+# are there, and even 0.2.3 predates this function. So PGXN isn't a usable
+# install source right now.
+#
+# Building straight from a git ref instead of PGXN is a supported way to
+# depend on an extension here, not just a one-off hack -- reach for it again
+# whenever a dependency's real state has moved ahead of what's tagged on
+# PGXN. What IS temporary is depending on cat_tools this way at all:
+# CAT_TOOLS_GIT_REF tracks cat_tools' `master` directly rather than a pinned
+# commit, since the function we need doesn't exist on any tagged release, so
+# there's nothing more stable to pin to yet. Once 0.3.0 is tagged and
+# published to PGXN, revert *this target* to a plain
+# `pgxn install 'cat_tools>=0.3.0' --sudo`; leave the git-source mechanism
+# itself in place for reuse if this happens again.
+CAT_TOOLS_GIT_REF = master
+CAT_TOOLS_BUILD_DIR = tmp/cat_tools-build
+
 .PHONY: cat_tools
 cat_tools: $(DESTDIR)$(datadir)/extension/cat_tools.control
 $(DESTDIR)$(datadir)/extension/cat_tools.control:
-	pgxn install 'cat_tools>=0.2.1' --sudo
+	rm -rf $(CAT_TOOLS_BUILD_DIR)
+	git clone https://github.com/Postgres-Extensions/cat_tools.git $(CAT_TOOLS_BUILD_DIR)
+	cd $(CAT_TOOLS_BUILD_DIR) && git checkout $(CAT_TOOLS_GIT_REF)
+	$(MAKE) -C $(CAT_TOOLS_BUILD_DIR) install PG_CONFIG=$(PG_CONFIG) DESTDIR=$(DESTDIR)
+	rm -rf $(CAT_TOOLS_BUILD_DIR)

README.md

@@ -4,7 +4,13 @@ Run custom commands when an extension is dropped. By default, `DROP
 EXTENSION` simply drops all the objects the extension owns; this lets you
 register additional SQL to run when a given extension is dropped.
 
-Requires [cat_tools](https://pgxn.org/dist/cat_tools/) >= 0.2.1.
+Requires [cat_tools](https://github.com/Postgres-Extensions/cat_tools) >= 0.3.0.
+Note: as of this writing, cat_tools 0.3.0 has not been tagged/published to
+PGXN yet, so the `cat_tools` build dependency is temporarily installed
+straight from its `master` branch rather than via `pgxn install` -- see the
+`Makefile`. This will revert to a plain `pgxn install` once 0.3.0 is
+published; building from a git ref is itself a supported fallback for this
+kind of gap, not a one-off hack.
 
 ## Functions
 

RELEASE.md

@@ -11,6 +11,33 @@ Releases use pgxntool's built-in `make tag`/`make dist` mechanics to produce a
 be uploaded to PGXN Manager by hand. See "Future: CI automation" below for the
 planned upgrade path.
 
+## Critical: never cut a release while a dependency is pinned to a git source
+
+Some dependencies are occasionally built from a pinned git ref instead of a
+real PGXN-published version, when the version we actually need hasn't been
+tagged yet (see e.g. the `Makefile`'s `cat_tools` target and
+`CAT_TOOLS_GIT_REF`). While a pin like that is active, this distribution's
+declared dependency floor (`META.in.json`'s `prereqs`) isn't actually
+satisfiable via `pgxn install` — cutting a real release in that state
+produces a citable, default-installable zip (`pgxn install` needs no special
+flags to fetch a `stable` release) that can't actually be built by anyone who
+downloads it from PGXN.
+
+**Before starting step 1 below**, grep the `Makefile` for any
+`_GIT_REF`/`_GIT_SHA`-style pinned-dependency variables. If any exist, stop —
+either wait for the real dependency version to land on PGXN, or otherwise
+resolve the pin, before proceeding.
+
+`bin/in_release` exists to help catch this: it exits true when
+`HISTORY.asc`'s top heading is a real version number rather than the
+`STABLE` placeholder used while changes are still accumulating (see
+"Ongoing development" below) — i.e., true exactly when we're sitting at (or
+about to cut) a release rather than mid-development. A pin existing while
+`bin/in_release` is true is exactly the state to avoid. This isn't wired into
+CI yet — that would need a generic, machine-checkable way to know "a pin
+exists" across whatever dependency needs one at the time, not just
+`cat_tools` specifically — so for now it's a manual check.
+
 ## Ongoing development (every PR, between releases)
 
 Keep the next release ready to cut at any time:
@@ -40,7 +67,9 @@ a changelog or an upgrade path from scratch under time pressure.
    **Caveat:** as of this writing, CI passing doesn't actually mean the test
    suite passed — see "CI doesn't fail on test failures" below. Until that's
    fixed, also eyeball the actual `pg_regress` output in the CI logs (or run
-   `make test` locally), not just the green checkmark.
+   `make test` locally), not just the green checkmark. **Also check for a
+   dependency pin** — see "Critical: never cut a release while a dependency
+   is pinned to a git source" above — before proceeding.
 
 2. Rename the accumulated `STABLE` markers to the real version number:
    - Edit `META.in.json`: bump the top-level `version` field AND the matching

bin/in_release

@@ -0,0 +1,9 @@
+#!/bin/sh
+# True (exit 0) when HISTORY.asc's top heading is a real released version
+# number rather than the `STABLE` placeholder used while changes are still
+# accumulating toward the next release -- i.e., true exactly when we're
+# sitting at (or about to cut) a release rather than mid-development. See
+# RELEASE.md.
+set -eu
+cd "$(dirname "$0")/.."
+[ "$(head -n1 HISTORY.asc)" != "STABLE" ]