postgresql: replace pg_config with custom script #388807
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
wolfgangwalther
commented
Mar 10, 2025
| @@ -466,6 +461,8 @@ let | |||
| postgresql = this; | |||
| }; | |||
|
|
|||
| pg_config = buildPackages.callPackage ./pg_config.nix { inherit (finalAttrs) finalPackage; }; | |||
There was a problem hiding this comment.
This should make it work nicely for cross-compilation, @rhelmot. I tried a very simple extension in nix-build -A pkgsCross.x86_64-freebsd.postgresql.pkgs.pgtap, which built fine. It's a SQL-only extension, which essentially only depends on pg_config, so builds fine without your follow ups.
(had to cherry pick the --with-uuid=bsd change, ofc)
Currently, this extension fails to build on master, because pg_config can't be executed.
14 tasks
By replacing upstream's pg_config binary with a shell script, we: - gain the ability to run pg_config easily when cross-compiling, - can remove the fake pg_config in the default output, - can remove the pg_config wrapper script dealing with special cases. Some 20 years ago, pg_config *was* a shell script upstream, too. It was changed to a binary, when it was made "relocatable", so it would return paths depending on the location of the "postgres" binary. However, this is exactly the thing that just hurts us in nixpkgs - we don't want those paths to change, we want them to always point at the right outputs. By writing the script ourselves, this becomes a lot less painful. This approach means more lines of codes, but all of them are dead simple and we have a lot less complexity overall. Additionally, pg_config is now made a separate derivation, only exposed as "postgresql.pg_config". This has the nice side-effect, that all users of postgresql and libpq in nixpkgs must be very *explicit* about their dependency on pg_config. This gives a lot more visibility into the state of affairs regarding pkg-config support for libpq, which ultimately is the much better solution.
wolfgangwalther
force-pushed
the
postgresql-pg-config
branch
from
c733b7b to
b0c6789
Compare
|
This is fantastic, thank you so much for putting in the effort to build this! I will need to take some time to pick this onto my dev branch and test it out end-to-end. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
By replacing upstream's pg_config binary with a shell script, we:
Some 20 years ago, pg_config was a shell script upstream, too. It was changed to a binary, when it was made "relocatable", so it would return paths depending on the location of the "postgres" binary. However, this is exactly the thing that just hurts us in nixpkgs - we don't want those paths to change, we want them to always point at the right outputs. By writing the script ourselves, this becomes a lot less painful.
This approach means more lines of codes, but all of them are dead simple and we have a lot less complexity overall.
Additionally, pg_config is now made a separate derivation, only exposed as "postgresql.pg_config". This has the nice side-effect, that all users of postgresql and libpq in nixpkgs must be very explicit about their dependency on pg_config. This gives a lot more visibility into the state of affairs regarding pkg-config support for libpq, which ultimately is the much better solution.
I only tested the postgresql extensions, so far - they all seem to work with this just fine. Everything outside the
postgresqlfolder, I did not touch, yet.TODO:
postgresqlandlibpq, passing pg_config were needed.Things done
Add a 👍 reaction to pull requests you find important.