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
postgresql14Packages.promscale_extension breaks with:
Error:
0: `pgx-0.6.1` shouldn't be used with `cargo-pgx-0.7.4`,
please use `pgx = "~0.7.4"` in your `Cargo.toml`.
However, pinning cargo-pgx to 0_6_1 via the following
buildPgxExtension.override { cargo-pgx = cargo-pgx_0_6_1; }
does not work either, because the build then fails with:
thread 'main' panicked at /build/promscale_extension-0.8.0-vendor.tar.gz/proc-macro2/src/fallback.rs:756:9:
"__mbstate_t_union_(unnamed_at_/nix/store/ij144ma6vs8acil8r9hgr8xkb1dp9azg-glibc-2_39-5-dev/include/bits/types/__mbstate_t_h_16_3)" is not a valid Ident
This seems to be related to [1], which indicates that this is a
problem with newer LLVM / clang toolchains.
At the same time th upstream package is deprecated / archived since
the 2nd of April 2024 [2]. Additionally this package is unfree and
thus very unlikely to be forked. Since we can't expect this to be
fixed, the only sensible thing to do is to remove the package.
[1]: https://github.com/rust-lang/rust-bindgen/issues/2312
[2]: https://github.com/timescale/promscale/issues/1836
pg_safeupdate was updated to 1.5 in #269755. v1.5 is not compatible with
PostgreSQL 12 and 13 anymore, so those were marked as broken.
However, this blocks anyone using PostgreSQL 12 or 13 with pg_safeupdate
from updating nixpkgs.
Instead, the old version should have been kept for PG 12 and 13.
Previously the entire `meta` section from `pg-dump-anon` was copied
over including `mainProgram` which doesn't belong here. To avoid similar
issues, fields from the meta section of pg-dump-anon are copied over
explicitly.
The nixpkgs-unstable channel's programs.sqlite was used to identify
packages producing exactly one binary, and these automatically added
to their package definitions wherever possible.
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.
