postgresql: provide PL/Perl, PL/Python and PL/Tcl as packages

[wolfgangwalther]

This follows up on #372655 (comment) and allows this:

postgresql.withPackages (pgps: [ pgps.plpython3.withPackages (pyps: [ pyps.base58 ]) ])

The same is done for plperl and pltcl.

While the extensions are split at run-time, they are still built in the main postgresql build and only stored in separate outputs. This allowed me to enable them by default, which has the following benefits:

• Those code paths are tested, they were not before. Neither tclSupport nor perlSupport worked properly before.
• Users avoid rebuilds when actually using them.
• They are not provided out of the box, reducing the attack surface for stuff like https://www.postgresql.org/support/security/CVE-2024-10979 (and if only by being able to confidently say "nope, I don't have it installed").

This is a breaking change for users of pythonSupport.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
• Tested, as applicable:
  • and/or package tests
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[wolfgangwalther]

Tested by cherry-picking onto master, since some reverse dependencies are currently broken on the base of staging that I am using here right now. All builds succeeded.

[wolfgangwalther]

Rebased and added release notes. This should build on this branch as well now, but will confirm.

[SuperSandro2000]

LGTM

[wolfgangwalther]

This should build on this branch as well now, but will confirm.

LLVM still broken on this branch for aarch64 (darwin+linux), but as said above, this builds fine on master.

---

@Ma27 any objections?

[Ma27]

I'm thinking out loud for a moment:

We can easily build postgres with tcl/python/perl support by default given the closure-size overhead is rather small (and at least python/perl are on most systems anyways).
Now, wouldn't it be easier to give the wrapper the ability to not only add postgresql extensions to its env, but also tcl/perl/python packages? E.g.

postgresql.buildEnv {
  postgresqlExtensions = ps: [ ... ];
  python3Packages = ps: [ ... ];
  python3Interpreter = pkgs.python3;
}

and let postgresql.withPackages be a wrapper for this (I'd argue that this is still what you want in most cases and I'd expect the fallout of just deprecating it rather high).

I'm wondering if this is a little simpler than splitting the pl* part into their own outputs and then "re-importing" this via the extension loading wrapper.

The implementation looks good so far.

Oh, and I'd like to apologize for not reviewing this earlier: was kinda busy with university exam stuff and being sick, so I didn't have the spoons for reviewing larger PRs.

[wolfgangwalther]

We can easily build postgres with tcl/python/perl support by default given the closure-size overhead is rather small (and at least python/perl are on most systems anyways).

I agree here.

Now, wouldn't it be easier to give the wrapper the ability to not only add postgresql extensions to its env, but also tcl/perl/python packages? E.g.
[...]
and let postgresql.withPackages be a wrapper for this (I'd argue that this is still what you want in most cases

The one thing you can't do easily with your approach: Get rid of PL/Python and PL/Perl. At least not without rebuilding. That's the cool thing about my approach: Everything is built, but you still have a choice!

This is something that people might want to be able to do. I certainly don't want to ship PL/Perl, when I don't need it.

I'm wondering if this is a little simpler than splitting the pl* part into their own outputs and then "re-importing" this via the extension loading wrapper.

It would probably turn out simpler, although I find the split not too bad. But I might be biased, just having written the code. Not sure how my future self would think about it in 6 months ;)

[wolfgangwalther]

Now, wouldn't it be easier to give the wrapper the ability to not only add postgresql extensions to its env, but also tcl/perl/python packages? E.g.

postgresql.buildEnv {
  postgresqlExtensions = ps: [ ... ];
  python3Packages = ps: [ ... ];
  python3Interpreter = pkgs.python3;
}

One thing that came to my mind is how to deal with 3rd party extensions implementing procedural languages - those might need a similar interface.

We currently package PL/R and PL/v8, but there are others like PL/Rust, PL/Haskell, PL/Java etc. as well. I assume some of those might need similar interfaces to provide packages - so it would be more consistent overall to have all of them work the same way instead of having some of them work via postgresql.buildEnv and others via the extension itself.

[wolfgangwalther]

We currently package PL/R and PL/v8, but there are others like PL/Rust, PL/Haskell, PL/Java etc. as well. I assume some of those might need similar interfaces to provide packages - so it would be more consistent overall to have all of them work the same way instead of having some of them work via postgresql.buildEnv and others via the extension itself.

I added the same interface to PL/R, which demonstrates the similarity / consistency of this approach.

[wolfgangwalther]

Rebased to resolve merge conflicts. Will merge later today.