Update nixpkgs / simplify static build

[wolfgangwalther]

Updating to a more recent nixpkgs version allows us to significantly simplify the static build expression - almost all required changes have been upstreamed by now.

Upstream nixpkgs has removed PostgreSQL 12, so according to our policy we drop support for it as well. Put that into the first commit. @steve-chavez would you like us to cut a new release first or are we OK to drop support for PG12 with the next release as well?

[wolfgangwalther]

Hm, the docs-related jobs fail in CI, but pass locally for me.

[wolfgangwalther]

Hm, the docs-related jobs fail in CI, but pass locally for me.

Should be working now, had to fix some non-ascii single and double quotes. A bit sad, that our tooling doesn't support those, but ultimately it's good for consistency.

[steve-chavez]

@steve-chavez would you like us to cut a new release first or are we OK to drop support for PG12 with the next release as well?

@wolfgangwalther Since we already announced dropping support only until v11 (here), could we leave this for a next major?

Updating to a more recent nixpkgs version allows us to significantly simplify the static build expression

I saw you were doing some great work on Nix to allow the above. Would we lose that simplification if we keep pg 12? Or would it be possible to reuse those Nix expressions and accommodate a build of pg12 on our own repo?

[wolfgangwalther]

TLDR: There is no need to hurry with this, however we should stick to our policies. And we really need to follow through with OpenAPI / Template Haskell, because that starts to block essentially every other update we are going to make.

Since we already announced dropping support only until v11 (here), could we leave this for a next major?

Well, that's exactly what I am proposing, right? We are overdue with a new release for quite some time and whatever we release from the main branch now is the next major.

But yes, we need to update the docs: PostgreSQL 12 is now deprecated as well, because it is EOL already - which is our rule according to the docs you cited.

Would we lose that simplification if we keep pg 12?

That simplification is only about the static build, which is not affected by another import of an earlier version of nixpkgs, so no, we would not lose that. We don't need to update nixpkgs immediately, but:

• Once we want to follow through with Build static executable for linux aarch64 (w/o TH) #3866 we certainly need to.
• Once a new postgresql minor version is released, we better do - because we want the libpq we build our static executable against to be the latest and greatest. But then again, this will only make a difference if we actually make a release at all.
• Once we want to support the newer hasql versions >= 1.7, because they require GHC 9.6... but then we need to do Build static executable for linux aarch64 (w/o TH) #3866, too...

Or would it be possible to reuse those Nix expressions and accommodate a build of pg12 on our own repo?

We agreed on the policy of "remove everything that is EOL", because that's the same policy that nixpkgs uses and we don't want to import older versions of nixpkgs at the same time, due to closure size for CI.

So we agreed on a policy regarding old versions - but whenever I remove them, you are not really happy about it :). Do we actually have agreement, then? :D

---

In any case, it seems like we are currently blocked by Nix on MacOS. It can't bootstrap GHC - I'm not sure whether that will fix itself, once we update to GHC 9.6 / 9.8 or not.

[steve-chavez]

So we agreed on a policy regarding old versions - but whenever I remove them, you are not really happy about it :). Do we actually have agreement, then? :D

My bad. It's just a knee-jerk reaction since I know some local government installations that are on old pg versions and refuse to upgrade since PostgreSQL upgrades are hard. I always think that it's best to support older pg versions as long as we can. But I forget that we can document that for older pg versions you can also use an older PostgREST version.

But yes, we need to update the docs: PostgreSQL 12 is now deprecated as well, because it is EOL already - which is our rule according to the docs you cited.

Cool, I agree. Let's drop pg 12 then.

[wolfgangwalther]

But I forget that we can document that for older pg versions you can also use an older PostgREST version.

Yes, it would be great to have some kind of "support matrix", where you can easily see which version of PostgREST supports which versions of PostgreSQL. Maybe in the README.

[wolfgangwalther]

Once a new postgresql minor version is released, we better do - because we want the libpq we build our static executable against to be the latest and greatest. But then again, this will only make a difference if we actually make a release at all.

There have been multiple minor released since then, I think - and we should really update by now.

In any case, it seems like we are currently blocked by Nix on MacOS. It can't bootstrap GHC

This is fixed and works now, so no blockers anymore.

[wolfgangwalther]

For some reason, I still get this failing IO test frequently:

 =================================== FAILURES ===================================
_______________________________ test_jwt_errors ________________________________
defaultenv = {'PGDATABASE': 'postgres', 'PGHOST': '/tmp/postgrest/postgrest-with-postgresql-17-hmH/socket', 'PGRST_DB_CONFIG': 'true', 'PGRST_DB_POOL': '1', ...}
    def test_jwt_errors(defaultenv):
        "invalid JWT should throw error"
    
        env = {**defaultenv, "PGRST_JWT_SECRET": SECRET, "PGRST_JWT_AUD": "io tests"}
    
        relativeSeconds = lambda sec: int(
            (datetime.now(timezone.utc) + timedelta(seconds=sec)).timestamp()
        )
    
        with run(env=env) as postgrest:
            headers = jwtauthheader({}, "other secret")
            response = postgrest.session.get("/", headers=headers)
            assert response.status_code == 401
            assert response.json()["message"] == "No suitable key or wrong key type"
            assert (
                response.json()["details"] == "None of the keys was able to decode the JWT"
            )
    
            headers = jwtauthheader({"role": "not_existing"}, SECRET)
            response = postgrest.session.get("/", headers=headers)
            assert response.status_code == 401
            assert response.json()["message"] == 'role "not_existing" does not exist'
    
            # -31 seconds, because we allow clock skew of 30 seconds
            headers = jwtauthheader({"exp": relativeSeconds(-31)}, SECRET)
            response = postgrest.session.get("/", headers=headers)
>           assert response.status_code == 401
E           assert 200 == 401
E            +  where 200 = <Response [200]>.status_code
test/io/test_io.py:108: AssertionError
----------------------------- Captured stdout call -----------------------------
- - - [11/Jul/2025:13:39:25 +0000] "GET / HTTP/1.1" 401 133 "" "python-requests/2.32.3"
- - not_existing [11/Jul/2025:13:39:25 +0000] "GET / HTTP/1.1" 401 92 "" "python-requests/2.32.3"
- - postgrest_test_anonymous [11/Jul/2025:13:39:25 +0000] "GET / HTTP/1.1" 200 18371 "" "python-requests/2.32.3"
--------------------------- snapshot report summary ----------------------------
6 snapshots passed.
=========================== short test summary info ============================
FAILED test/io/test_io.py::test_jwt_errors - assert 200 == 401
 +  where 200 = <Response [200]>.status_code
============= 1 failed, 205 passed, 1 skipped in 89.65s (0:01:29) ==============

[wolfgangwalther]

After a few retries CI passes now for all IO tests. This still needs to be looked into if it keeps occurring, but will merge now.

[taimoorzaeem]

Sometime after this PR, I sometimes get the following error on postgrest-build:

<no location info>: error: [-Wmissed-extra-shared-lib, -Werror=missed-extra-shared-lib]
    libHSpostgrest-13.1-inplace.so: cannot open shared object file: No such file or directory
    It's OK if you don't want to use symbols from it directly.
    (the package DLL is loaded by the system linker
     which manages dependencies by itself).

It doesn't interfere with anything, but makes me question if something is wrong with my setup.

[wolfgangwalther]

Interesting, I see something similar:

Building test suite 'spec' for postgrest-13.1...
[ 9 of 51] Compiling SpecHelper       ( test/spec/SpecHelper.hs, dist-newstyle/build/x86_64-linux/ghc-9.4.8/postgrest-13.1/t/spec/build/spec/spec-tmp/SpecHelper.o, dist-newstyle/build/x86_64-linux/ghc-9.4.8/postgrest-13.1/t/spec/build/spec/spec-tmp/SpecHelper.dyn_o ) [Source file changed]

<no location info>: error:
    libHSwarp-3.3.31-JO7nj4DQAHh6TYH6v5RNWQ-ghc9.4.8.so: cannot open shared object file: No such file or directory
Error: [Cabal-7125]
Failed to build test:spec from postgrest-13.1.

This does interfere with building the tests for me, though.

After doing a postgrest-clean, I now start seeing the same error as you do, but also without interference.

[wolfgangwalther]

For now, I'd probably just wait and see whether this remains to be the case after upgrading GHC eventually.