Skip to content

Converge 0.2.3 update path to fresh install and test all update origins#46

Merged
jnasbyupgrade merged 5 commits into
Postgres-Extensions:masterfrom
jnasbyupgrade:comprehensive-update-tests
Jul 21, 2026
Merged

Converge 0.2.3 update path to fresh install and test all update origins#46
jnasbyupgrade merged 5 commits into
Postgres-Extensions:masterfrom
jnasbyupgrade:comprehensive-update-tests

Conversation

@jnasbyupgrade

@jnasbyupgrade jnasbyupgrade commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

The 0.2.0->0.2.2 and 0.2.1->0.2.2 update scripts create cat_tools.trigger__parse with a body that hardcodes ' EXECUTE PROCEDURE ' and omits the empty-args guard, while a fresh install matches ' EXECUTE (?:PROCEDURE|FUNCTION) ' and guards empty args. On PG11+ the server emits EXECUTE FUNCTION, so the hardcoded ' EXECUTE PROCEDURE ' never matches: the split leaves the argument list NULL and the function errors with "cannot determine type of empty array" on every trigger it parses (not just the first, and not only triggers that take no arguments). Any pre-0.2.2-origin database therefore breaks as soon as it reaches PG11+ via pg_upgrade. The 0.2.2->0.2.3 update now appends a CREATE OR REPLACE FUNCTION with the fresh body verbatim; CREATE OR REPLACE preserves grants and the comment, has no dependents to break, and is a no-op on a fresh 0.2.2 (which already has the corrected body). 0.2.3 is not yet published, so converging the fix forward in its update script is the intended fix rather than patching the immutable 0.2.x scripts.

A structural comparison (pg_get_functiondef / pg_get_viewdef / type labels / comments / ACLs / extension membership) of a fresh 0.2.3 install versus a 0.2.2->0.2.3 in-place update was run to hunt for any other fresh-vs-update divergence. The only other difference was relation__kind / relation__relkind, whose stored bodies carried pg_class.h reference comments in the fresh source that the update-script bodies lacked; the update-script bodies now carry the same comments so the update path converges byte-for-byte with fresh (verified: empty prosrc diff for relation__kind, relation__relkind, and trigger__parse).

With the divergence fixed, the CI matrix is broadened to exercise every supported update origin. pg-upgrade-test restores the old_pg=10 legs to old_install=0.2.0 (they had been temporarily pinned to a fresh 0.2.2 to dodge the trigger__parse bug) and adds a 0.2.1-origin 10->18 leg, so both pre-0.2.2 origins bridge-update to 0.2.3 on PG10 and then survive binary pg_upgrade across majors with the full suite. extension-update-test gains a rebuild_021 (0.2.1->0.2.3) check paralleling rebuild_020, so both pre-0.2.2 origins prove the pg_class_v rebuild strips relhasoids in-place on PG10. The 0.2.2 origin keeps its existing in-place update-scenario (PG12-18) and pg_upgrade legs. Supported update origins are 0.2.0/0.2.1/0.2.2; 0.1.x is not supported.

Local validation on PG17: the 0.2.2->0.2.3 in-place update structurally matches a fresh 0.2.3 install (empty diff across functions, views, types, comments, ACLs, extension membership) and the full existing-mode suite passes. The PG10-origin legs are validated in CI only (this environment has no PG10).

Two comment cleanups ride along, applied identically to the fresh source (sql/cat_tools.sql.in) and the 0.2.2->0.2.3 update script so the two bodies stay byte-identical: the trigger__parse function-arguments note is switched to block-comment format per the repo style, and the relation__kind pg_class.h comment drops a confusing enumeration of three of the eight relkind values in favor of a bare pg_class.h reference.

🤖 Generated with Claude Code

jnasbyupgrade and others added 2 commits July 21, 2026 16:01
…comments)

The 0.2.0->0.2.2 / 0.2.1->0.2.2 update scripts create cat_tools.trigger__parse with a body that hardcodes ' EXECUTE PROCEDURE ' and omits the empty-args guard, whereas a fresh install has a body that matches ' EXECUTE (?:PROCEDURE|FUNCTION) ' and guards empty args. On PG11+ the server emits EXECUTE FUNCTION, so a pre-0.2.2-origin database that reaches PG11+ (via pg_upgrade) errors with "cannot determine type of empty array" the first time the suite parses a trigger. Append a CREATE OR REPLACE FUNCTION to the 0.2.2->0.2.3 update script with the fresh body verbatim; CREATE OR REPLACE preserves grants and the comment and is a no-op on a fresh 0.2.2.

A structural diff (pg_get_functiondef/viewdef/type labels/comments/ACLs/extension membership) of a fresh 0.2.3 install versus a 0.2.2->0.2.3 in-place update also surfaced that relation__kind/relation__relkind stored bodies differ only by two explanatory /* ... pg_class.h ... */ comments present in the fresh source but absent from the update-script bodies. Add those comments so the update path converges byte-for-byte with fresh.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Restore the pg-upgrade-test old_pg=10 legs to old_install=0.2.0 (they were temporarily pinned to a fresh 0.2.2 to dodge the trigger__parse divergence, now fixed in the 0.2.2->0.2.3 update) and add a 0.2.1-origin 10->18 leg so both pre-0.2.2 origins are proven to bridge-update to 0.2.3 on PG10 and then survive binary pg_upgrade across majors. Parallel the extension-update-test PG10 rebuild_020 check with rebuild_021 (0.2.1->0.2.3) so both pre-0.2.2 origins prove the pg_class_v rebuild strips relhasoids in-place. Rewrite the now-stale comment that described the 0.2.2 workaround.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Jul 21, 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: c231c55f-62c8-45b5-a20c-78dcacdf4d32

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
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

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 21, 2026 16:03
The two 10 → 18 legs (0.2.0 and 0.2.1 origins) otherwise render with an
identical check name.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Per the repo's SQL style, multi-line explanations use block comments, not
runs of -- lines. The comment is changed identically in the fresh source and
the 0.2.2->0.2.3 update script so the two trigger__parse bodies stay
byte-identical (the convergence this PR establishes); verified on PG17 that
fresh-install and 0.2.2->0.2.3 prosrc remain identical.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Enumerating only c/f/m out of the eight relkind values was arbitrary and
confusing in a function that maps all of them; reduce it to a bare pg_class.h
reference. Changed identically in the fresh source and the 0.2.2->0.2.3 update
script so the bodies stay byte-identical; verified on PG17 that fresh-install
and 0.2.2->0.2.3 prosrc remain identical for relation__kind, relation__relkind,
and trigger__parse.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@jnasbyupgrade
jnasbyupgrade merged commit f5fa068 into Postgres-Extensions:master Jul 21, 2026
28 checks passed
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