Real update path: recover 0.1.1, author 0.1.1→stable diff (depends on #26 for the stable rename)

[jnasbyupgrade]

Migrated from fork-internal PR jnasbyupgrade#7 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#7

---

Update: This PR previously also did the default_version rename (1.0.0 -> stable) inline. That's been split out into #26 at the owner's request, since it's a separate, independently-mergeable concern (pure versioning/docs) from the update-path testing infrastructure below. This PR's base is now rename-1.0.0-to-stable (#26's branch) instead of test-install-foundation directly, since the update-path testing work here genuinely depends on both: the test/install/ harness from test-install-foundation (#19) and the stable rename from #26 (the update-diff script's target, and what bin/test_update_path.sh asserts the version lands at). Since rename-1.0.0-to-stable branches off fix-cat-tools-install as a sibling of test-install-foundation rather than stacking under it, this PR's "Files changed" tab will show test-install-foundation's own files too until #19 merges (a GitHub diff-scoping artifact of depending on two sibling branches at once, not new/duplicated content) -- it no longer shows any default_version/HISTORY.asc/META changes, since those now live solely in #26.

Summary

extension_drop's real 0.1.1 install script (2017, its only actual PGXN
release) was never committed to this repo -- only ever generated as a
build artifact and uploaded directly to PGXN. As a result, no update-diff
script has ever existed either, despite a real SQL change between 0.1.1
and the current stable source (the client_min_messages removal in
HISTORY.asc). Anyone who actually installed 0.1.1 from PGXN had, and
until this PR merges still has, no ALTER EXTENSION UPDATE path forward
at all.

This is real, valuable, buildable-right-now work -- it does not depend on
cat_tools shipping a real PGXN 0.3.0, or on this extension being formally
released. It only rides on this branch stack because CI needs cat_tools
installed from git-source (already solved by the base of this stack)
rather than PGXN, and because it needs the stable rename (#26) to know
what to update to.

What's in this PR

• Recovered the real 0.1.1 install script from PGXN's dist archive:
  https://api.pgxn.org/dist/extension_drop/0.1.1/extension_drop-0.1.1.zip
  (URL confirmed working, confirmed against
  https://api.pgxn.org/dist/extension_drop.json). Committed byte-for-byte
  as sql/extension_drop--0.1.1.sql. Added DATA += sql/extension_drop--0.1.1.sql
  to the Makefile -- pgxntool's base.mk DATA wildcard only picks up the
  current version file plus two-dash update scripts, not other historical
  single-version files (already filed as Postgres-Extensions/pgxntool#48).

• The actual delta, found by diffing recovered 0.1.1 against current
  sql/extension_drop.sql, turned out to be three things, only one of
  which needs replaying in an update script:

  1. extension_drop__event_trigger() gained one RAISE DEBUG line at
     entry -- a real, persisted function body change. This is the only
     thing sql/extension_drop--0.1.1--stable.sql does (a single
     CREATE OR REPLACE FUNCTION).
  2. The client_min_messages save/restore removal HISTORY.asc already
     documents -- but that code only ever ran inside the install script's
     own session and never left anything in the extension's persisted
     state, so an already-installed 0.1.1 has nothing to clean up here.
  3. A cat_tools function rename (function__arg_types_text ->
     routine__parse_arg_types_text, not previously documented in
     HISTORY.asc -- found via git log -S on sql/extension_drop.sql,
     landed in the "Fix misnamed function call" part of Switch to GitHub Actions and update pgxntool #1) -- but that
     call only happens transiently inside the install script's internal
     __extension_drop.create_function() builder to compute REVOKE/GRANT
     argument lists; it's never stored in any persisted function body, so
     it doesn't affect an already-installed 0.1.1 either. (Also: cat_tools
     0.3.0 keeps the old name as a deprecated wrapper, so a fresh CREATE EXTENSION extension_drop VERSION '0.1.1' still works today for
     testing this exact path.)

• default_version rename (1.0.0 -> stable) now lives in Rename default_version from 1.0.0 to stable #26, not
  here -- see that PR for details. This PR's update-diff script
  (sql/extension_drop--0.1.1--stable.sql) and bin/test_update_path.sh
  both depend on it having landed.

• Wired up a real, CI-exercised update-path leg. TEST_UPDATE_FROM
  now defaults to 0.1.1 (previously required explicitly, with no safe
  default, since there was nothing real to point it at). Added
  bin/test_update_path.sh, a committed/parameterized script (not inline
  YAML) that: installs 0.1.1, plants the dependency-guard view, proves a
  non-CASCADE DROP EXTENSION is blocked, runs ALTER EXTENSION extension_drop UPDATE, re-proves the guard still blocks the drop, and
  dynamically asserts (empty-value-guarded, not hardcoded) that the
  installed version now matches extension_drop.control's
  default_version. The new extension-update-test CI job runs this
  script, then make test-update to run the full pgTAP suite (including
  dependency_guard) against the updated result.

  This job runs as a single job on PG17 rather than a second full PG
  matrix: extension_drop's install/update scripts have nothing
  catalog-version-sensitive in them (no pg_upgrade/omit_column-style
  concerns), so it's a PG-version-agnostic, SQL-level concern layered onto
  the matrix approach the rest of this stack already uses, not something
  that needs its own axis.

Local verification (PG17, this container)

$ bin/test_update_path.sh
...
OK (pre-update, at 0.1.1): non-CASCADE DROP EXTENSION extension_drop is blocked by the dependency guard
OK (post-update): non-CASCADE DROP EXTENSION extension_drop is blocked by the dependency guard
OK: extension_drop landed at 'stable' after update, matching extension_drop.control's default_version
PASS: 0.1.1 -> stable update path verified (install, guard survival, version assertion).

$ make test-update    # full pgTAP suite in update mode
ok 1 - ../install/load
ok 2 - dependency_guard
ok 3 - schema
ok 4 - simple
ok 5 - zzz_build
# All 5 tests passed.

$ make test           # fresh mode, unaffected
# All 5 tests passed.

Test plan

• Locally: install 0.1.1 -> ALTER EXTENSION UPDATE -> lands at
  stable -> dependency guard survives -> full pgTAP suite passes
  (update mode)
• Locally: fresh install (now landing at stable) still passes the
  full suite
• CI: existing test matrix (fresh install, PG 9.3-17) stays green
• CI: new extension-update-test job passes

[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: 5bc172b0-e786-49b2-9df3-936e6cbd6c12

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