feat: support multiple versions of the pg_tap extension

[jfroche]

Build multiple versions of the pg_tap extension on different PostgreSQL versions.
Add test for the extensions and their upgrade on PostgreSQL 15 and 17.

Summary by CodeRabbit

• New Features
  • Added pgtap extension support (1.2.0, 1.3.1, 1.3.3) with multi-version packaging; the latest version is selected by default and version-specific artifacts and metadata are provided.
  • Added a package-level alias to install all pgtap versions and improved discoverability of per-version info.
• Tests
  • pgtap added to the extension test matrix to validate compatibility across supported PostgreSQL majors.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[hunleyd]

rebase to fix conflicts?

[coderabbitai]

Walkthrough

Replaces the single-derivation pgtap export with a buildEnv-based multi-version factory driven by versions.json; produces per-version packages (with version-specific fetch/patch/install logic) and exposes aggregated paths, pathsToLink, and passthru metadata.

Changes

Cohort / File(s)	Summary
Multi-version pgtap build factory nix/ext/pgtap.nix	Replaces a top-level stdenv.mkDerivation export with a buildEnv that constructs per-version derivations from versions.json. Adds data-driven version parsing, per-version fetch/build (including optional patch for 1.3.3 and special-case 1.3.1 C extension), custom installPhase producing control/SQL/so artifacts, and exposes paths, pathsToLink, and passthru (versions, numberOfVersions, pname-all, multi-version version). Adds public inputs buildEnv and fetchpatch2.
Extension version registry nix/ext/versions.json	Adds pgtap entry with versions: 1.2.0 (postgresql: ["15"]), 1.3.1 (postgresql: ["15","17"]), 1.3.3 (postgresql: ["15","17"]) and their SHA256 hashes.
Test extension matrix nix/ext/tests/default.nix	Adjusts test matrix: inserts pg_partman and replaces another occurrence with pgtap, modifying which extensions are exercised by the tests.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Poem

🐇 I hopped from one build to many with glee,
JSON gave versions and set them all free,
I fetched, I patched, I stitched each part,
Bundled control files, SQL, and a tiny C heart,
Hooray — pgtap now nests for every PG tree!

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	❓ Inconclusive	The description is brief but clearly states the main objectives: building multiple versions of pg_tap on different PostgreSQL versions and adding tests. However, it lacks detail about implementation specifics and the description template appears to require more structured information.	Consider using the repository's PR description template (Default or Extension Upgrade) to provide more structured information about changes, testing approach, and any breaking changes.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the primary change: adding support for multiple versions of the pg_tap extension, which is reflected in the versioning mechanism, multi-version builds, and JSON configuration.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@nix/ext/pgtap.nix`:
- Around line 66-69: The sed invocation is using an undefined shell variable
`$ext`, so `module_pathname` will be wrong; fix by defining `ext` (e.g., set ext
to the correct shared-object path) before the sed call or replace `$ext` inline
with the correct path expression, and if the package may not build a C
extension, change the logic around `${pname}.control` generation (in the block
that runs sed and touches `${pname}--${version}.control`) to conditionally omit
the `module_pathname` line when `src/pgtap.so` (or the built shared object) does
not exist.

🧹 Nitpick comments (1)

nix/ext/pgtap.nix (1)

86-89: Hardcoded version check for C extension symlink.

The condition "${version}" == "1.3.1" is hardcoded. If a future pgtap version reintroduces a C extension, this logic won't automatically handle it. Consider documenting this decision or making the check more robust (e.g., based on whether the .so file exists and this is not the latest version).

♻️ Alternative approach

-        elif [[ "${version}" == "1.3.1" ]]; then
-          # 1.3.1 is the first and only version with a C extension
-          ln -sfn ${pname}-${version}${postgresql.dlSuffix} $out/lib/${pname}${postgresql.dlSuffix}
+        elif [[ -f src/pgtap.so && "${version}" != "${latestVersion}" ]]; then
+          # Create default symlink for non-latest versions with C extension
+          ln -sfn ${pname}-${version}${postgresql.dlSuffix} $out/lib/${pname}${postgresql.dlSuffix}
         fi

[coderabbitai]

Actionable comments posted: 2

🤖 Fix all issues with AI agents

In `@nix/ext/pgtap.nix`:
- Around line 9-29: Add a guard after computing supportedVersions/versions to
fail with a clear message when no matching entries exist: compute versions as
you do, then compute numberOfVersions (or use builtins.length versions) and use
lib.assert (or an explicit check) to ensure numberOfVersions > 0, failing with a
message that includes the current postgresql.version; this prevents lib.last
(latestVersion) from being called on an empty list and makes the error explicit.
- Around line 66-90: The control-file rewrite currently unconditionally replaces
module_pathname (using ext) which can point to a missing shared library for
SQL-only releases; change the logic so the sed rewrite that sets module_pathname
to $ext only runs when the shared library exists (the same test used for
src/pgtap${postgresql.dlSuffix}), and for SQL-only versions remove the
module_pathname line entirely (or leave it omitted) from the generated
${pname}--${version}.control so CREATE EXTENSION won't reference a non-existent
library.