feat: add pg-search container image

[philippemnoel]

Extension

Adds a CloudNativePG extension image for ParadeDB's pg_search extension, based on ParadeDB's existing docker/Dockerfile.extension. The image supports PostgreSQL 18 on Debian Bookworm and Trixie for amd64 and arm64.

The image:

• installs the official ParadeDB release .deb with per-platform SHA-256 verification;
• ships pg_search.so, control/SQL files, and license notices in a FROM scratch payload;
• stages the non-base OpenBLAS and gfortran shared libraries under /system;
• configures shared_preload_libraries and ld_library_path metadata;
• adds a metadata-only pgvector stub so the required upstream vector extension resolves during E2E testing; and
• documents Cluster and Database resources.

Closes #14

Contributor checklist

• Commit is GPG-signed and signed off for DCO compliance.
• History is a single commit with the required feat: add ... format.
• PR targets main.
• New Extension Proposal exists and is linked above.
• metadata.hcl records package/catalog version 0.25.6 and the required runtime configuration.
• create_extension = true matches the packaged pg_search.control.
• The final image is FROM scratch, uses UID/GID 65532, and contains only extension artifacts, required linked libraries, and licenses.
• README includes working Cluster and Database examples.
• CODEOWNERS names @philippemnoel as component owner.
• I confirm my commitment to maintain this extension.

Validation

• git diff --check
• Trixie/amd64 Docker build
• Bookworm/arm64 Docker build
• Verified final payload contains pg_search.so, extension SQL/control files, libopenblas.so.0, libgfortran.so.5, and corresponding notices
• Full Kind/Chainsaw E2E (left to CI; local Task/Dagger tooling is unavailable)

The repository bake definitions parse both new metadata files and expand their complete Bookworm/Trixie matrix. Local buildx bake --check reached export, then hit a local-driver limitation for index annotations; direct representative builds passed.

[ardentperf]

Thanks for this! It motivated me to actually get this project production ready. I spent a ton of time over the past couple days cleaning things up.

I think I've fixed all the branding (the original name "Not CNPG" was a funny reference to the licensing issue, but this name "CNPG Extensions" is much more professional).

But more importantly, I'm pretty sure that I now have all of the CI working - renovate and the OS dependency checker are watching for any updates to packages or their dependencies, and trigger automatic updates here.

I also set up a local artifacts repository and got the Extension Catalog working. The catalog here in CNPG Extensions is layered on top of the official CloudNativePG extension catalog. That means that users can simply update their catalog to point here instead of CNPG and they will have a full catalog of auto-updating extensions including both everything here and everything official. Catalogs are updated once a week and pull in all updates from upstream.

Refactored tests with a very minimal change to the dagger code so that we dont need stubs anymore - since we have catalogs, realized we can leverage them to solve this more cleanly.

Everything has minimal change so that I can continue to track upstream cloudnative-pg extension container repo and merge updates to CI. I've also contributed a few fixes I found upstream.

---

For pg_search, two things off the top of my head. First, we can remove the pgvector stub - shouldn't need it anymore with the updates. Second, I'd like to scrutinize how dependencies are handled a bit. I want to make sure that we have clear provenance, that it's transparent how the binary is being built and what version of every dep are used, and I want to make sure that updates to dependencies reliably trigger rebuilds.

Separately I'm looking into pg_parquet which is another rust-based postgres extension. I'm kinda interested to spend a little time researching if there might be a better way to containerize a rust-based postgres extension. Debian packages that run on the official Debian build infra have very strong dependency management (they scan binaries for function references). Is pg_search producing dynamically linked libraries? Are we reliably detecting shared library dependencies? Are there any?

[ardentperf]

FYI - I had an AI agent run the same scan of the provided upstream Debian packages that I did for cloudnative-pg#117

does seem like this debian package is also missing the license info

i'm going to put the summary here below - but i'm not too worried because this will be addressed by the pgrx build framework i'm putting together for this repo.

---

pg_search Debian license report

Audit date: 2026-09-13

Summary

The pg_search source graph has complete license expressions and license text for all 851 Rust crates checked. The downloaded Debian packages do not carry that per-dependency information: they contain only the project-level AGPL license and Debian copyright notice. Therefore, the pg_search DEBs are missing Rust dependency license information.

Inputs

The Debian packages were downloaded from the ParadeDB v0.25.6 release:

Package	Download URL	SHA-256
Bookworm amd64	DEB	88bed17a4b7e084ae20ea481ee2e20fa9d210323fc3fc104021bad5cbcb9855f
Bookworm arm64	DEB	8e52aaca5ea79e90617b93e9add11b3d8a8428e2afe9c4617fe5510cf9a043fa
Trixie amd64	DEB	752cd6000bda74f9751bbc41855fd394fda1db58a505db7a52e2b8f134090e0b
Trixie arm64	DEB	3fe3019a0d56e918a9f567c8286a37892187bb5c6e5eae1c53e41beccb651cf0

The upstream lockfile checked by the source audit was Cargo.lock at v0.25.6. The local checkout used the source archive at the same tag.

Methodology

1. Inspected cnpg-extensions/postgres-extensions-containers#13 and the upstream release assets.
2. Downloaded all four PG18 Debian variants above and verified their SHA-256 values against the GitHub release metadata.
3. Extracted the packages with dpkg-deb and searched package contents and control metadata for license, copyright, notice, SPDX, Cargo, and SBOM information.
4. Ran the local source-build license workflow from pgrx/install-pgrx-build-environment.sh. It generated CycloneDX and cargo-about output using Cargo.lock, --locked, and --fail for PostgreSQL 18.
5. Checked that every crate in cargo-about.json had a non-empty license expression and every generated license record had license text.

Findings

The DEB packages contain only these license-related paths:

/usr/share/doc/postgresql-18-pg-search/LICENSE
/usr/share/doc/postgresql-18-pg-search/copyright

The Debian copyright file applies AGPL-3.0-or-later to Files: *. It is an aggregate project notice; it does not list the Rust crates, their versions, their license expressions, or their third-party license texts. ScanCode detected AGPL in both documentation files, with no scan errors.

The source audit found:

Check	Result
Rust crates in cargo-about graph	851
Crates with license expressions	851 / 851
License records with text	232 / 232
Crates missing license expressions	0
Generated unique Rust license-text files detected by ScanCode	14 / 14

The source graph used these license identifiers: AGPL-3.0, Apache-2.0, BSD-2-Clause, BSD-3-Clause, BSL-1.0, CC0-1.0, CDLA-Permissive-2.0, ISC, MIT, MPL-2.0, NCSA, Unicode-3.0, and Zlib.