postgresql: add new feature options

[wolfgangwalther]

This makes almost everything that PostgreSQL supports to be built with available as xSupport flags. Bonjour only works on darwin, selinux only on Linux - all others seem to work fine on both, except for a failed output check on darwin with ldap enabled. I don't consider that critical for now, though.

The idea here is to provide those options - and then have separate discussions and much more tests if we decide to turn any of them on by default.

Supersedes #218934 and makes #345289 a tiny bit nicer to implement.

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
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 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
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[Ma27]

This gives me a different derivation than on the merge-base with master. I'm pretty sure this is because the order of buildInputs is different, hence this is a mass-rebuild and will need to target staging[1].

Sure, we could also retain the order, but I think this would make the expression weirder than it needs to be, so I think just waiting is OK.

[1] Kinda sucks that ofborg got even slower so I have to de facto do those checks on my again 🙄

[wolfgangwalther]

This gives me a different derivation than on the merge-base with master. I'm pretty sure this is because the order of buildInputs is different

Ah, good catch. I wasn't 100% sure and wanted to let ofborg tell me about that. But you are quicker than ofborg is. ;)

[1] Kinda sucks that ofborg got even slower so I have to de facto do those checks on my again 🙄

Yeah, it's so annoying currently.. most of my PRs are waiting for OfBorg multiple days. The feedback cycle is soo slow.

[Ma27]

most of my PRs are waiting for OfBorg multiple days

I've been told that it's probably not possible anymore for the workers to keep up with the stream of incoming PRs (+ that it's probably not getting cheaper to perform those evaluations).

There are people trying to use GHA more (and also movements to keep ofborg running with more hardware sponsored from several parties), let's hope that one of those things works out.

[emilazy]

We already do have GHA‐based evaluation; that’s what the “Outpaths” jobs on this PR are.

[Ma27]

We already do have GHA‐based evaluation; that’s what the “Outpaths” jobs on this PR are.

Yep, seen those.
To me the proposal sounded like a full-blown ofborg replacement though, i.e. tooling to also tell me the rebuild count sooner or later, hence the wording.

[emilazy]

You can download the outpaths from the action result to get the data, but yes, no fancy labelling as of yet AFAIK.

[Ma27]

I think it has the outpaths only, but not the diff (and thus rebuild count) from what I see in the zipball.

Anyways, from what I see, I'm positively surprised then, nice.