fix(release): installable releases and images on a pinned Debian

[blitss]

Why

Deploying 0.4.x onto a database created with ghcr.io/blitss/typeid-pg:v0.1.0-docker (PG 16, bookworm) turned up a chain of breakages in the release tooling:

1. install.sh can't install any published release. Since c38e997 it requires RELEASE_VERSION, a <asset>.sha256 sidecar and a lib/ + share/extension/ archive layout, with a fixed member list that stops at 0.3.0--0.4.0. The release workflow never produces sidecars and packs the build host's Debian paths (usr/lib/postgresql/<pg>/…).
2. The image build and the PR migration check depend on that script. The Dockerfile pipes install.sh from main, and test-migrations calls it without RELEASE_VERSION, so the next release's images and every PR's Migration job fail. The v0.4.1 images exist only because they were built on Aug 11, before that commit.
3. postgres:<pg> is Debian trixie now (glibc 2.41). Putting a bookworm data directory (glibc 2.36) under it makes Postgres warn collation version mismatch, and text indexes need a REINDEX.
4. Race between jobs. The image job only waited for the build job, while the assets come from the release job.

What

• release.yaml: packaging. Archives contain lib/typeid.{so,dylib} and share/extension/typeid.control + typeid--*.sql, files only, plus a <asset>.sha256 sidecar (<digest> <asset>). Both are uploaded and attached to the release.
• install.sh. The archive is checked by pattern: exactly one library, the control file, typeid--<RELEASE_VERSION>.sql required, any other typeid--*.sql allowed. Everything listed is installed.
• Dockerfile. FROM postgres:${PG_VERSION}-${DEBIAN} (default trixie). It runs the install.sh from the build context with RELEASE_VERSION.
• release.yaml: images. Built for debian: [bookworm, trixie] with tags <pg>-<debian> and <version>-<pg>-<debian>; <pg>, latest and <version> stay on trixie. The image job needs: release.
• test-migrations.yaml. Installs the latest release with install.sh when it has a sidecar, else unpacks the old Debian-layout tarball.
• Readme. Documents the tags, and says to run ALTER EXTENSION typeid UPDATE right after switching images. The 0.4.1 library dropped type_id_min_state_wrapper, type_id_max_state_wrapper, typeid_ge_wrapper and typeid_uuid_generate_v7_wrapper, which 0.1.0's SQL objects reference, so min()/max() over typeids fail until the update.

Verified locally

• install.sh, local mode, on postgres:16-bookworm. Fed v0.4.1's pg16/arm64 files repacked exactly as the new packaging step does. Result: checksum OK, installed, CREATE EXTENSION gives 0.4.1, typeid_generate works. Asking for RELEASE_VERSION=0.4.2 with that archive is refused (missing required member: share/extension/typeid--0.4.2.sql).
• Image on bookworm. Built with DEBIAN=bookworm: glibc 2.36, PG 16.15.
• Upgrade path. 0.1.0 with 50k rows and a text unique index on v0.1.0-docker, then the bookworm image on the same volume, then ALTER EXTENSION typeid UPDATE. Result: 0.4.1, IMMUTABLE comparisons, min() works, the typeid join is a Hash Join (~45 ms vs a ~100 s nested loop before), no collation warning.

After merging

The first release cut with this (e.g. v0.4.2) produces installable assets and the bookworm images. A new tag also publishes to PGXN, which is permanent.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-06T14:33:57.791093Z	c13f1a4	New commits

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.