Some extensions compile their JIT bitcode with debug info: postgis
passes autoconf's default CFLAGS ("-g -O2") through PG_CPPFLAGS, and
pg_textsearch hard-codes -g there. The DIFile entries then reference
headers in clang-wrapper, glibc-dev, postgresql-dev and other -dev
outputs, pulling the whole LLVM toolchain into the runtime closure.
Native objects are stripped, but the bitcode is not.
PostgreSQL already runs nuke-refs on its own bitcode, so do the same
for extensions. SQL-only extensions have no lib/, hence the check.
On x86_64-linux with PostgreSQL 18, this shrinks the closure of postgis
from 2.8 GiB to 654 MiB and of pg_textsearch from 2.4 GiB to 40 MiB.
JIT inlining from the processed postgis bitcode was verified to still
work.
Assisted-by: Claude Code (Claude Opus 5.5)
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 is for consistency with postgresqlTestExtension and
postgresqlTestHook. Everything that is passed via postgresql's
generic.nix "packages scope" now is prefixed with "postgresql".
