Repository navigation
Conversation
Contributor
Author
|
I've added |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR prepares the pg_stat_ch extension for distribution on PGXN (PostgreSQL Extension Network) by changing the extension schema version format from 0.1.0 to 0.1 while maintaining the release version at 0.1.7. The simplified version format allows binary-compatible minor releases without requiring version-specific SQL migration files for each patch release.
Changes:
- Renamed SQL installation file from
pg_stat_ch--0.1.0.sqltopg_stat_ch--0.1.sqlto match new version format - Added PGXN release infrastructure including META.json metadata, Makefile for PGXS compatibility, and automated release workflow
- Configured git export rules to exclude development files from distribution packages
Reviewed changes
Copilot reviewed 7 out of 9 changed files in this pull request and generated 13 comments.
Show a summary per file
| File | Description |
|---|---|
| sql/pg_stat_ch--0.1.sql | New SQL installation file with simplified version number (0.1 instead of 0.1.0) |
| cmake/GitVersion.cmake | Updated fallback version from "0.1.0" to "0.1" |
| benchmark/Dockerfile | Updated to reference new SQL filename pg_stat_ch--0.1.sql |
| Makefile | New PGXS-compatible Makefile for standard PostgreSQL extension builds and PGXN distribution |
| META.json | New PGXN metadata file describing extension, maintainers, dependencies, and resources |
| CLAUDE.md | Updated documentation to reflect new SQL filename |
| .gitignore | Added pattern to ignore release artifact zip files |
| .github/workflows/pgxn.yml | New workflow to automate PGXN releases on tagged commits |
| .gitattributes | New export rules to exclude development files from distribution archives |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 7 out of 9 changed files in this pull request and generated 4 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
theory
force-pushed
the
pgxn
branch
3 times, most recently
from
February 17, 2026 23:43
c9406fc to
0abc885
Compare
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 8 out of 10 changed files in this pull request and generated 3 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Change the extension version from `0.1.0` to `0.1`, but keep the release
version at `0.1.7`. This allows binary-compatible minor releases without
the need for version-specific SQL migration files.
Add a workflow to release on PGXN. Details:
* Add a simple `Makefile` so that typical PGXS-style tooling works. It
doesn't actually use PGXS except to determine the shared library
suffix. The `installcheck` is a to-do for now.
* Add `.gitattributes` to prevent files we don't want distributed from
being included in the release.
* Include submodules in the release, so that builds will work.
* Add `META.json` to describe the extension to PGXN.
serprex
reviewed
Feb 24, 2026
| container: pgxn/pgxn-tools | ||
| steps: | ||
| - name: Check out the repo | ||
| uses: actions/checkout@v4 |
Member
There was a problem hiding this comment.
Suggested change
| uses: actions/checkout@v4 | |
| uses: actions/checkout@v6 |
Contributor
Author
There was a problem hiding this comment.
All of them use @v4; should keep them in sync and update in a separate PR, no?
serprex
approved these changes
Feb 24, 2026
3 tasks
amogiska
added a commit
that referenced
this pull request
May 5, 2026
* chore(meta): align extension version with distribution (0.3) and bump 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. * fix(meta): rewrite 0.1→0.3 migration to drop+recreate pg_stat_ch_stats 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. * fix(meta): make 0.1→0.3 migration conditional on catalog shape 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. * chore(meta): drop fabricated 0.1.sql, simulate legacy state in regression 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. * fix(meta): resolve stats function via extension membership, fix expected 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.
Change the extension version from
0.1.0to0.1, but keep the release version at0.1.7. This allows binary-compatible minor releases without the need for version-specific SQL migration files.Add a workflow to release on PGXN. Details:
Makefileso that typical PGXS-style tooling works. It doesn't actually use PGXS except to determine the shared library suffix. Theinstallcheckis a to-do for now..gitattributesto prevent files we don't want distributed from being included in the release.META.jsonto describe the extension to PGXN.