chore(meta): align extension version with distribution (0.3)#84
Merged
chore(meta): align extension version with distribution (0.3)#84
Conversation
… to 0.3.7 The control file's `default_version` had been pinned at `0.1` while distribution releases moved to `0.3.x`, so users installing the 0.3.6 release ended up with `0.1` showing in `\dx`. Per the versioning policy from #33, the extension version (major.minor) should track the distribution version family. - Bump `default_version` from `0.1` to `0.3` in pg_stat_ch.control. - Rename sql/pg_stat_ch--0.1.sql to sql/pg_stat_ch--0.3.sql. - Add a no-op sql/pg_stat_ch--0.1--0.3.sql migration so existing `0.1` installs can `ALTER EXTENSION pg_stat_ch UPDATE TO '0.3'` (the SQL surface is unchanged between the two versions). - Bump META.json distribution version to 0.3.7 for the next release.
The first cut of this migration was a no-op, which was wrong. Even
though SQL contents at HEAD match the historical 0.1.sql for three
of the four functions, pg_stat_ch_stats() gained an 11th OUT
column (dsa_oom_count) in v0.3.5 — but the extension's
default_version stayed at '0.1' through v0.3.6, so installs from
v0.1.x – v0.3.4 still have the 10-column variant in their catalog
and only return 10 columns when called against the v0.3.7 binary.
That's exactly the "binary incompatible change in the DSO" case
Theory called out: a real migration is required.
- Migration drops and recreates pg_stat_ch_stats() with the 11
OUT columns. Idempotent for v0.3.5+ installs that already have
the 11-column shape.
- Restore sql/pg_stat_ch--0.1.sql (10-column historical variant)
alongside the canonical 0.3.sql so `CREATE EXTENSION pg_stat_ch
VERSION '0.1'` continues to work and the upgrade path is
testable end-to-end.
- Add test/regression/{sql,expected}/upgrade — installs at 0.1,
asserts pg_stat_ch_stats has 10 OUT params, runs UPDATE TO
'0.3', asserts it has 11 and the new column is queryable.
- Wire the new regression test into scripts/run-tests.sh and the
GitHub Actions workflow.
The unconditional DROP FUNCTION pg_stat_ch_stats() broke the upgrade path for v0.3.5/v0.3.6 installs whose catalog already had the 11-column shape but extversion='0.1' (because default_version was never bumped). If such a database had a view depending on pg_stat_ch_stats(), the DROP would fail with a dependency error even though the catalog needed no change. Wrap the rewrite in a DO block that only fires when the live function has fewer than 11 OUT parameters (the v0.1.x..v0.3.4 shape). For installs that already match the canonical shape, the migration is a true no-op and any dependent objects are left untouched. Expand test/regression/upgrade with a second scenario that constructs the "11 cols + extversion='0.1' + dependent view" state (install fresh 0.3, attach a view, force extversion back to '0.1') and asserts the migration leaves both the function and the view intact.
…sion test The previous commit restored a 10-column sql/pg_stat_ch--0.1.sql to make the upgrade regression test natural. But shipping that file is a fiction: the released v0.3.5 / v0.3.6 distributions ship 0.1.sql with 11 columns (PR #62 mutated it in place). Re-fabricating the historical 10-column file just to test against would misrepresent what users actually have on disk, and there is no real reason to ship a 0.1 SQL file going forward (fresh installs use 0.3, existing installs only need the migration). Drop sql/pg_stat_ch--0.1.sql. Rewrite the regression test to construct both the legacy 10-column and the v0.3.5+ 11-column states directly via catalog manipulation (drop the function from the extension, recreate with the desired shape, force pg_extension.extversion = '0.1') after a fresh 0.3 install. Both scenarios then exercise the conditional in 0.1--0.3.sql end-to-end.
iskakaushik
approved these changes
May 5, 2026
…ted output Two issues from review: 1. The shape check hard-coded `pronamespace = 'public'::regnamespace`. The extension is non-relocatable but its install schema is whatever `CREATE EXTENSION pg_stat_ch SCHEMA <name>` set it to, not necessarily public. For an install in a non-public schema with the already-correct 11-column function, the lookup would miss, current_outargs would be NULL, and the migration would attempt DROP FUNCTION on a function the query couldn't find — failing if the function had dependents. Switch to a pg_depend join that finds the pg_stat_ch_stats function owned by the pg_stat_ch extension regardless of schema, and tighten the guard from `IS DISTINCT FROM 11` to `= 10` so only the legacy shape ever triggers a rewrite. 2. Expected upgrade.out was missing the trailing space pg_regress emits on column header rows, so the diff would fail in CI even when the migration produced the right results. Add the trailing spaces; separator widths already accounted for them.
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
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
default_versionfrom0.1to0.3inpg_stat_ch.controlso a freshCREATE EXTENSION pg_stat_chreports0.3in\dx(matches the distribution0.3.xfamily — was reporting0.1even on the0.3.6release).sql/pg_stat_ch--0.1.sql→sql/pg_stat_ch--0.3.sqland add a no-opsql/pg_stat_ch--0.1--0.3.sqlmigration so existing0.1installs canALTER EXTENSION pg_stat_ch UPDATE TO '0.3'(SQL surface unchanged between the two).META.jsondistribution version0.3.6→0.3.7for the next release.Per the versioning policy from #33, the extension
default_version(major.minor) should track the distribution version family.Test plan
CREATE EXTENSION pg_stat_ch;then\dxshows version0.3.0.3.6(extension version0.1), upgrade to this build, runALTER EXTENSION pg_stat_ch UPDATE TO '0.3';,\dxshows0.3.META.json0.3.7once tagged.