The withPackages scope now provides a "postgresqlTestExtension" helper
which removes all the boilerplate for those kind of tests.
This was Mario Rodas' idea in #299756.
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
We introduced LTO in #294504. At that time, we still needed to use LLVM
/ lld to make this work on darwin. For this to work for extensions, they
would need to set CFLAGS=-fuse-ld=lld, too. However, since #307880
landed, we don't need to do this anymore in the first place, LTO just
works out of the box on darwin.
Resolves#342362
The !isDarwin condition seems to have been put in place only because of the
use of patchelf, which in turn seemed to be necessary because of nuke-refs.
Replacing the big nuke with the more granular remove-references-to allows
enabling this for darwin, too.
This splits a dev output to make the default output not depend on any
build dependencies anymore. This also avoids removing references from
pgxs' Makefile this way, which should, at least theoretically, be good
to build extensions via pgxs, making sure they use the same tooling.
ecpg is the "embedded SQL C preprocessor", which is certainly a dev
tool.
Most important, for closure size anyway, is to move pg_config to the dev
output, since it retains paths to all the other outputs.
The only thing with references to the dev output remaining is then the
postgres binary itself. It contains all the output paths, because it
shows those in the pg_config system view. There is no other way than
to nuke those references to avoid circular dependencies between outputs
- and blowing up closure size again.
This library is used by other packages, so should be in the lib output.
By removing unused sections, libecpg will not contain any references to other
outputs and thus does not increase the closure for the lib output anymore.
This will also help massively when splitting a dev output later.
As a side-effect, this also unbreaks pkgsMusl.postgresql_12_jit and
pkgsMusl.postgresql_13_jit. For, at least to me, unknown reasons, those build
fine now.
Dynamic modules are technically libraries, but are not used by other packages.
Instead they are loaded by PostgreSQL itself, e.g. as extensions. Those just
increased the size of the lib output without benefit.
This removes the NIX_PGLIBDIR hack introduced in #17838 and instead makes sure
that pg_config always returns the correct PGLIBDIR. The test for postgis
introduced in the same PR is still passing with the change.
pgx had been renamed to pgrx in April 2023 already [1]. Newer versions
are already in nixpkgs as pgrx. Since the previous commit removed
the only remaining instance of a package still depending on
pgx 0.6.1, we can now remove all of buildPgxExtension and cargo-pgx.
[1]: https://github.com/pgcentralfoundation/pgrx/issues/1106
This was introduced in #228349, but doesn't seem necessary to build for pkgsMusl.
In fact the patch itself seems to be very specific about a stripped down icu
package in Alpine Linux, which does not apply to nixpkgs.
This was disabled to fix#51093. The related discussion upstream revealed that this
has been fixed in [1] for v12+. Since v12 is our oldest supported version right now,
we should be able to safely enable parallel building on darwin again.
Furthermore, it seems that this kind of issue was also fixed in #51221 and #51408
for the general case.
[1]: 826eff57c4
This was introduced in #44083 to fix cross building, where xml2-config
wouldn't run on the host platform. This was fixed upstream two years
later [1], so that from v13 on pkg-config is used before xml2-config is.
Once v12 is EOL, we can remove this entirely.
[1]: 0bc8cebdb8
This was introduced in 65fd8f3f48 around 20 years
ago as LANG=en_US, later changed to LC_ALL=en_US and LC_ALL=C to avoid bash
warnings. This might have been relevant to run initdb during the check phase, but
the PostgreSQL docs [1] say this today:
For implementation reasons, setting LC_ALL does not work for this purpose
Therefore it can be removed safely.
[1]: https://www.postgresql.org/docs/current/regress-run.html#REGRESS-RUN-LOCALE
Trying to understand what each patch does made me come up with some more
descriptive names:
- Renaming the two disable-xxx patches to a common names makes it immediately
clear that one replaces the other depending on version number.
- findstring was really not descriptive at all.
- hardcode-pgxs-path will be extended with more paths for split outputs in
a later commit. Renaming here already to allow git to better track renames.
Finally replacing HARDCODED_PGXS_PATH with $out/lib in the last patch, makes
it easier to understand what the end result will look like when reading the
patch.
Previously, it was not possible to run tests on an overridden derivation, because
the derivation under test was always pulled from pkgs.
With this change, the following will return the same test:
postgresql_jit.tests
and
(postgresql.override { jitSupport = true; }).tests
We have gssSupport, jitSupport and pythonSupport - but enableSystemd?
Across nixpkgs there are currently three styles commonly used, about equally
often: withX, xSupport and enableX.
Let's at least use one consistent style in this package.
This was proposed by abbradar in #150801, but left out of the follow up PR
#221851 by Ma27 to reduce the size of the diff. Compared to the initial
proposal this includes the callPackage call in the recursion, which avoids
breaking the withJIT/withoutJIT helpers.
In terms of nixpkgs, this is a pure refactor, no derivations change. However,
this makes downstream expressions like the following possible:
(postgresql.override { jitSupport = true; }).pkgs.postgis
This would have not worked before without passing another "this" argument,
which is error prone as can be seen in this example:
https://github.com/PostgREST/postgrest/pull/3222/files
This makes it less error-prone to use the llvm package in extensions, because
it will always match the package used by the postgresql derivation itself.
Previously, you could've accidentally used llvm instead of postgresql.llvm
with a different result.
This makes it obvious that the required argument muslPatches must be passed when
creating a new version file.
Pure refactor, not changing any derivations.
This seems to have been introduced 20 years ago in 5863d4f - but
seems to have been a copy&paste mistake from the beginning.
AFAICT, it's not used anywhere.
Refactors some low hanging fruit in default.nix to make it easier to add new
versions later on.
Pure refactor, not changing any derivations.
This change makes it easier to add new versions in default.nix without messing
up - and also prevents us from adding version-specific arguments in default.nix
by accident in the future. Those should be put in the versioned .nix files
instead.
The recommended [1] structure for a package regarding versioning is to have each
version in a separate file. This commit just mechanically copies code around
without any changes.
Pure refactor, not changing any derivations.
[1]: pkgs/README.md
This just renames default.nix to generic.nix, because the biggest chunk
of code should move that way in the next commit. This gives us a much
better diff for the next commit and makes rebasing **much** easier in
case of changes. This commit does not stand on its own and needs to go
in with the next commit (2/2).
