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.
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).
This commit is split up into two commits to allow git to detect renames,
make rebasing easier and allow a working entry in .git-blame-ignore-revs.
To allow bisecting we allow evaluation on every commit by moving the extensions
into ext/ext/ first and back to ext/ with the next commit.
This is a Go program inside the sources of `postgresql_anonymizer` that
allows to perform database dumps, but with anonymized data. I figured
that it's a little awkward to have a client program to be part of the
extension package.
So I decided to create a second package called `pg-dump-anon`. Since
it's one repository, both share `version` & `src`.
Also extended the VM test to make sure we're getting properly anonymized
data when dumping with `pg_dump_anon`.
https://github.com/plv8/plv8/blob/v3.1.10/Changes
3.1.10 is currently not the latest version - 3.2.2 is. However, the 3.2 branch needs
more changes to build successfully. The update to 3.1.10 makes this package build
with postgresql_16 for now.
This failed because libpam, which postgresql is now linked against, was missing as a
build input. In general, this is an indication that this extension needs the same
build inputs that postgresql was built with - so we just pass those instead.
This makes similar build failures less likely in the future.
This failed because libpam, which postgresql is now linked against, was missing as a
build input. In general, this is an indication that this extension needs the same
build inputs that postgresql was built with - so we just pass those instead.
This makes similar build failures less likely in the future.
This failed because libxcrypt, which pg12 is linked against, was missing as a
build input. In general, this is an indication that this extension needs the
same build inputs that postgresql was built with - so we just pass those instead.
This makes similar build failures less likely in the future.
