Fix pgtle.sh rejecting non-numeric version aliases like 'stable' (#57)#63
Merged
jnasbyupgrade merged 3 commits intoJul 26, 2026
Conversation
…tgres-Extensions#57) extract_version_from_filename() required every version segment to start with a digit ([0-9][0-9.]*), so extensions using the persistent 'stable' pseudo-version convention (default_version = 'stable', with files like sql/<ext>--stable.sql and sql/<ext>--1.0.0--stable.sql) failed with "Cannot parse version from filename". pg_tle itself treats extension versions as opaque strings - check_valid_version_name() in pg_tle's tleextension.c only forbids empty strings, "--", and leading/trailing "-", with no numeric requirement. Widened the regex to the same rule: each version segment is now [^-]+(-[^-]+)*, matching how default_version is already treated everywhere else in pgxntool. Unrelated to this: pgtle.sh separately does real numeric version comparison in parse_version()/version_to_number()/get_version_dir(), but that parses pg_tle's own installed version to pick a capability tier (1.0.0-1.4.0 / 1.4.0-1.5.0 / 1.5.0+), not the extension's version - the digit-only regex here appears to have been copied from that unrelated logic.
|
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:
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
2 tasks
jnasbyupgrade
marked this pull request as ready for review
July 26, 2026 21:35
jnasbyupgrade
added a commit
to Postgres-Extensions/pgxntool-test
that referenced
this pull request
Jul 26, 2026
…#30) ## Summary Paired with pgxntool PR Postgres-Extensions/pgxntool#63, which fixes `pgtle.sh`'s `extract_version_from_filename()` rejecting non-numeric version aliases like `stable` (issue #57). - Adds one test, `pgtle: stable pseudo-version alias is not rejected (issue #57)`, right after the existing whitespace-parsing regression test in `test/sequential/04-pgtle.bats`. - It creates a temp control file plus a base numeric version file (`stable_test--1.0.0.sql`), a base `stable` version file (`stable_test--stable.sql`), and a numeric-to-stable upgrade path (`stable_test--1.0.0--stable.sql`), then runs `pgtle.sh --extension stable_test --pgtle-version 1.5.0+` and checks the generated SQL registers both versions, the upgrade path, and `set_default_version`. - Kept to a single consolidated `@test` (multiple related assertions) rather than splitting into several, per this repo's guidance on BATS per-test overhead. ## Test plan - [x] Full suite passes: 216/216, 0 failures, 0 skips (run against the `tletest` PG cluster, `PGCLUSTER=17/tletest PGPORT=5418`, so pg_tle coverage was fully exercised). - [x] New test confirmed passing end-to-end (`ok 54 pgtle: stable pseudo-version alias is not rejected (issue #57)`), driven through the full `pgtle.sh` CLI path.
jnasbyupgrade
added a commit
that referenced
this pull request
Jul 26, 2026
#63) It was being over-restrictive by mandating semantic versioning. Related changes in pgxntool-test: - Add coverage for the 'stable' pseudo-version alias in pgtle.sh (Postgres-Extensions/pgxntool-test#30, commit c25033e)
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.
Summary
Closes #57.
extract_version_from_filename()required every version segment to start with a digit ([0-9][0-9.]*), so extensions using the persistentstablepseudo-version convention (default_version = 'stable', with files likesql/<ext>--stable.sqlandsql/<ext>--1.0.0--stable.sql) failed outright withCannot parse version from filename.check_valid_version_name()in pg_tle'stleextension.conly forbids empty strings,--, and leading/trailing-, with no numeric requirement. Widened the regex to the same rule ([^-]+(-[^-]+)*per version segment), matching howdefault_versionis already treated everywhere else in pgxntool.HISTORY.ascentry under the unreleasedSTABLEheading.Note:
pgtle.shseparately does real numeric version comparison inparse_version()/version_to_number()/get_version_dir(), but that parses pg_tle's own installed version to pick a capability tier (1.0.0-1.4.0/1.4.0-1.5.0/1.5.0+), not the extension's version — the digit-only regex inextract_version_from_filename()appears to have been copy-adapted from that unrelated logic rather than being an intentional constraint.Test plan
test/sequential/04-pgtle.bats) exercises the fullpgtle.shCLI path with a base numeric version file, a basestableversion file, and a numeric-to-stable upgrade path.pgxntool-testsuite passes: 216/216, 0 failures, 0 skips.