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?