Real update path: recover 0.1.1, author 0.1.1→stable diff (depends on #26 for the stable rename) - #22
Draft
jnasbyupgrade wants to merge 6 commits into
Draft
Real update path: recover 0.1.1, author 0.1.1→stable diff (depends on #26 for the stable rename)#22jnasbyupgrade wants to merge 6 commits into
jnasbyupgrade wants to merge 6 commits into
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
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. Comment |
This was referenced Aug 4, 2026
jnasbyupgrade
changed the base branch from
test-install-foundation
to
rename-1.0.0-to-stable
August 4, 2026 22:53
jnasbyupgrade
force-pushed
the
real-update-path
branch
from
August 4, 2026 22:53
cc69f19 to
2e36592
Compare
jnasbyupgrade
changed the title
…, quoting-requiring schema test Builds the U&U (update & upgrade) test infrastructure that doesn't require a real second extension_drop version or pg_upgrade CI to already exist: - PGXNTOOL_ENABLE_TEST_INSTALL = yes, with test/install/load.sql as the committed-once installer for the extension (no test roles exist for this extension, so unlike cat_tools there's nothing role-related to add). - TEST_LOAD_SOURCE (fresh/update/existing) GUC/make-var switch, parse-time validated, exported unconditionally, read in load.sql without missing_ok. `existing` mode is fully exercised locally (verified against a real, already-installed database, including the failure path when the extension is genuinely absent). `update` mode is wired up and structurally verified end-to-end, but extension_drop has no real prior released version to update FROM yet -- the Makefile refuses to run it without TEST_UPDATE_FROM set explicitly, and no CI leg exercises it in this repo today. - Dependency guard (test/sql/dependency_guard.sql): a view depending on extension_drop__commands' row type blocks a non-CASCADE DROP EXTENSION; proven by actually attempting the drop and asserting failure, not assumed. - test/sql/schema.sql's custom-schema test names renamed to mixed case (requires identifier quoting), reusing its existing coverage rather than adding a new schema-testing dimension. - ci.yml: run `make test && make verify-results` instead of pg-build-test, so a real regression actually fails the build (pgxntool's .IGNORE: installcheck otherwise reports green regardless of test results, per RELEASE.md's existing note about PRs #6/#7). Moving the extension's own installation into test/install/load.sql required adapting every test file that used to install it per-test in a rolled-back transaction (test/deps.sql, test/sql/simple.sql, test/sql/schema.sql, test/sql/zzz_build.sql) to work against the new committed-once install instead, since an extension name is a database-wide singleton. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…redate this branch CI on this branch showed the switch to `make test && make verify-results` surfacing real pgTAP failures on PostgreSQL 9.3/9.6 (cat_tools/extension_drop never actually install there). Checked PR #10's own baseline CI (#10, run 30665031257): PG 9.3 and 9.6 already report "3 of 3 tests failed" in the raw job log there too, just silently reported as a passing check because pg-build-test's underlying `make test` hits pgxntool's `.IGNORE: installcheck` the same way. So this isn't a regression from this PR's own changes -- it's the exact masking problem RELEASE.md already documents, just now applying to a different, older part of the PG matrix than the PRs (#6/#7) it originally cites. Reverting the ci.yml step back to pg-build-test here keeps this PR scoped to test/install infrastructure; fixing cat_tools's install path on pre-PG10 belongs to whoever owns that dependency setup (PR #10 or a follow-up), not this PR. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
extension_drop's real 0.1.1 install script (2017) was never committed to this repo -- only ever generated as a PGXN dist build artifact and uploaded directly -- so no update-diff script has ever existed either, despite a real SQL change between 0.1.1 and the current `stable` source (removing redundant client_min_messages handling; see #24, which renamed default_version from the never-released "1.0.0" to `stable` and is a prerequisite for this branch). That left anyone who actually installed 0.1.1 from PGXN with no path forward at all. - Recover the real 0.1.1 sql/extension_drop.sql from PGXN's dist archive (https://api.pgxn.org/dist/extension_drop/0.1.1/extension_drop-0.1.1.zip) and commit it as sql/extension_drop--0.1.1.sql. Add it to DATA explicitly (pgxntool's DATA wildcard only picks up the current version file and two-dash update scripts, not other historical single-version files -- Postgres-Extensions/pgxntool#48). - Author sql/extension_drop--0.1.1--stable.sql: the actual delta is just extension_drop__event_trigger() gaining one RAISE DEBUG line (found by diffing recovered 0.1.1 against current source). The client_min_messages removal and a cat_tools function rename (function__arg_types_text -> routine__parse_arg_types_text) both turned out to be install-script-only behavior with nothing persisted to replay. - Default TEST_UPDATE_FROM to 0.1.1 and wire up a real extension-update-test CI job: installs 0.1.1, plants the dependency guard, runs ALTER EXTENSION UPDATE, re-proves the guard survived, dynamically asserts the version landed at stable, then runs the pgTAP suite in update mode. Factored into bin/test_update_path.sh so it's runnable locally, not just inline CI YAML. Verified locally against PG17: 0.1.1 install -> guard blocks non-CASCADE drop -> ALTER EXTENSION UPDATE -> guard still blocks drop -> version lands at 'stable' -> full pgTAP suite passes in both fresh and update modes. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
jnasbyupgrade
force-pushed
the
real-update-path
branch
from
August 4, 2026 23:12
2e36592 to
3add6cc
Compare
A separate extension-update-test job meant a whole extra container boot + PostgreSQL startup for a leg that needs no isolation of its own -- unlike pg_tle's job, which genuinely does. Runs as extra steps in each matrix leg's already-running container instead.
CREATE EXTENSION ... CASCADE only exists from PG10 -- the script crashed with a syntax error on the 9.3-9.6 matrix legs. Same branch test/install/load.sql already uses for the same reason.
cat_tools.routine__parse_arg_types_text() -- called unconditionally by extension_drop's install script, in both 0.1.1 and current -- hits cat_tools's hardcoded DROP ROUTINE internally, which doesn't exist before PG11. Not something to work around here: this is a real, pre-existing incompatibility affecting a fresh install of current extension_drop on PG9.3-10 too, just never surfaced by this repo's non-gating CI until this leg's ON_ERROR_STOP actually failed loudly.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Depends on #19 (test/install harness) and #26 (
stablerename) — stacked on both.Adds a real
ALTER EXTENSION UPDATEpath for extension_drop. Its only actualPGXN release, 0.1.1 (2017), never had its install script committed to this
repo — only generated as a build artifact and uploaded directly. No update
path existed as a result. This recovers it from PGXN's dist archive as
sql/extension_drop--0.1.1.sql, and addssql/extension_drop--0.1.1--stable.sqlto bring an existing 0.1.1 install up to
stable.TEST_UPDATE_FROMnow defaults to0.1.1.bin/test_update_path.sh: installs 0.1.1, plants the dependency guard,runs
ALTER EXTENSION UPDATE, re-proves the guard survives, asserts thelanded version dynamically against
extension_drop.control.testjob's matrix legs — noseparate CI job/container, since this leg needs no isolation of its own.
Verified locally (PG17)
ALTER EXTENSION UPDATE-> guard still blocks -> lands at
stableupdateandfreshmodesTest plan