This allows `postgresql.withPackages` to easily override the paths to
the default and man outputs for `pg_config`. It avoids all
`buildEnv`-dev-output hackery, which it didn't properly support, and
separates the logic cleanly.
Previously, pg_config would report the paths of the underlying
postgresql derivation and not the paths of the buildEnv that
postgresql.withPackages creates.
That's a problem when users of pg_config use it to find PostgreSQL's
sharedir, in which they'd like to find the extensions added via
withPackages. Those are only linked into the created buildEnv, but not
available in the postgresql derivation.
By providing our own nix-support/pg_config.env file, we can swap out
those paths. We also do the same for the -man output, because this
output is linked into buildEnv as well. Other paths, which are not
available in the buildEnv environment, will still link to the original
postgresql derivation. Win-win!
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.
This replaces `writeShellApplication` with `writeShellScriptBin` that
doesn't perform a shellcheck. This makes it way easier to build
postgresql on staging since GHC is super slow to build, even with pretty
powerful machines.
Also Haskell updates are currently merged straight into master which
means that postgresql and all reverse dependencies require a rebuild on
master then[1].
[1] https://github.com/NixOS/nixpkgs/pull/354270#issuecomment-2463196665
This fixes some build systems which look up the location of pg_config
via the location of the postgres binary itself, e.g. timescaledb,
instead of calling pg_config which is on PATH.
Since the -dev output is correctly placed before the default output of
postgresql in PATH, we can rely on that and call "pg_config" from the
default output's fake script. Only do that, when the one on PATH is
actually a different file, though, to prevent infinite loops.
Resolves#341408
