Repository navigation
Test the update path with pgxntool's fresh/update pattern - #10
jnasbyupgrade wants to merge 5 commits into
Conversation
The extension is now installed once, committed, by `test/install/load.sql`. `TEST_LOAD_SOURCE=update` (`make test-update`) runs the same suite and expected output against an install updated from `TEST_UPDATE_FROM` (0.2.0), and `bin/compare_fresh_vs_update` diffs every extension member against a fresh install; CI runs both. In update mode, `test/helpers/update_with_data.sql` stores a test language and templates under the old version, runs the update, checks that they still process by name and by `template_id`, and removes the language, leaving nothing behind. The language and template setup moves from `test/core/functions.sql` to `test/helpers/language_factory.sql` so the suite and the helper share it.
|
No actionable comments were generated in the recent review.
 |
| Check name | Status | Explanation |
|---|---|---|
| Title check |  |
The title clearly and concisely identifies the main change: testing the extension update path with the fresh/update pattern. |
| Description check | |
The description directly explains the update-mode test flow, comparison checks, CI changes, and related implementation details. |
| Docstring Coverage | |
No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentat… |
| Linked Issues check | |
Check skipped because no linked issues were found for this pull request. |
| Out of Scope Changes check | |
Check skipped because no linked issues were found for this pull request. |
Full details: Docstring Coverage
-
Explanation
No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 0 functions across 0 files. (9 skipped: 9 unsupported.)
Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Commit to this branch
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
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.
A rabbit checks the fresh install,
Then hops through updates, testing still.
It compares each snapshot pair,
And checks the templates are still there.
The carrots pass; the logs say “OK!”
Comment @coderabbitai help to get the list of available commands.
test/build/build.sql runs in pgxntool's isolated test-build pass, so it no longer drops the committed install or fights test/install. Check the post-update version in update_with_data.sql right after ALTER EXTENSION UPDATE, so a wrong version fails the run on every PG version. Assert that the test language's functions exist before template_language__remove(). Fix header and comment wording, and gate compare-fresh-vs-update's install dependency on PGXNTOOL_ENABLE_FS_INSTALL.
The pgxn/pgxn-tools image lacks rsync, which test-build needs.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
test/install/load.sqlinstalls the extension once, committed, before the suite runs.TEST_LOAD_SOURCE=updateruns the same suite and expected output against an install created atTEST_UPDATE_FROM(0.2.0) and then updated withALTER EXTENSION trunklet UPDATE.make test-updateruns that suite, thenbin/compare_fresh_vs_update, which diffs every extension member's definition, comments and ACL against a fresh install. CI runsmake verify-results, thenmake test-update, on every PostgreSQL version in the matrix.In update mode,
test/helpers/update_with_data.sqlstores a test language and one template, 'test template' with versions 1 and 2, under the old version before the update. After the update it checks that the template still processes by name and bytemplate_id. It then removes the language withtemplate_language__remove(), which drops the language functions the old version created. The run fails if any language function or row is left behind, and the sequences are reset, so the suite's expected output is the same in both modes. A failure of any check in the helper surfaces atloadon PG16+; on PG 9.5-15 it surfaces through the downstream tests such asallandsearch_path, since pg_regress reports thetest/installfile itself as ok.test/helpers/language_factory.sqldefines the language and template setup functions, and both the suite and the helper load it. The helper also checks thattrunkletis atdefault_versionright afterALTER EXTENSION UPDATE, so a wrong version fails the run.The build test is
test/build/build.sql, which pgxntool runs in its isolated test-build pass before the main suite. It has no committed install to drop, so it doesn't fighttest/install.test/sql/search_path.sqlstill drops the committed install inside its rolled-back test. There is noexistingmode and noTEST_UPDATE_TO.Updating from 0.2.0 or 0.2.1 changes the caller's
search_path. The0.2.0--0.2.1and0.2.1--0.3.0scripts save it from inside the script, where Postgres has already overridden it, andSETthat value back. The helper schema-qualifies everything after the update instead of relying onsearch_path. This PR does not change those scripts.