jackc
Requesting support for PostgreSQL 18
Is your feature request related to a problem? Please describe. Requesting support for PostgreSQL 18.
Describe the solution you'd like It would be great to add support for PostgreSQL 18, as the official release is expected very soon (RC1 is already available). Early compatibility would help ensure a smooth transition once it’s officially launched.
Additional context https://www.postgresql.org/docs/18/release-18.html
Tnx
Much needed . As we have support for UUID-v7 in postgres-18. And many more things.
Do you know of anything that needs to change? As far as I know everything should continue to work.
Do we have support for uuidv7 extraction of timestamp and operations around it . I cant see those particularly in uui datatype . For distributed system UUIDv7 is quite a. thing . Any help from your side will be appreciated @jackc
I think the only notable change from a driver perspective is the bumping of the wire protocol from 3.0 to 3.2. The changes seem to be fairly minimal based on the release notes which only mention increasing the cancel request keys to 256 bits and making it a variable length field. Ref: https://www.postgresql.org/docs/current/protocol-overview.html#PROTOCOL-VERSIONS
I'm open to supporting the new cancel request key size.
Oauth would be interesting too. Though I have no idea what that would actually look like.
For the Oauth part looks like we need few more parameters supported in the Config type at the very least as mentioned here https://www.postgresql.org/docs/18/libpq-oauth.html
I've made very simple oidc validator for the postgresql server side part to enable oauth here https://github.com/UnAfraid/pg_oidc_validator_rust in Rust and https://github.com/UnAfraid/pg_oidc_validator_go in Go
@UnAfraid thank you for sharing. I had something similar in mind when I started looking into this topic. I was wondering if we could use Kubernetes service accounts to authenticate with Postgres. This seems to work. I did put my demo setup here https://github.com/dvob/pg_oidc_validator
However, currently it does the OIDC discovery and fetch of the JWKS on every new connection. It would be nice if this could be cached somehow. My initial try with caching didn't work so I would have to take a closer look on how exactly Postgres loads validators and what options if any at all would be possible.
@UnAfraid thank you for sharing. I had something similar in mind when I started looking into this topic. I was wondering if we could use Kubernetes service accounts to authenticate with Postgres. This seems to work. I did put my demo setup here https://github.com/dvob/pg_oidc_validator
However, currently it does the OIDC discovery and fetch of the JWKS on every new connection. It would be nice if this could be cached somehow. My initial try with caching didn't work so I would have to take a closer look on how exactly Postgres loads validators and what options if any at all would be possible.
I initially tried to cache both the discovery and the jwk fetch, however i noticed that it always did the discovery, which seems to look like the library is loaded and unloaded after each authentication request
I've checked postgres source and it does indeed load the library on demand and then unloads it from memory, so in-memory caching isn't going to work, in case caching is needed we could use the file system e.g. in /tmp. But i am not sure if caching is even needed, usually there's connection pool.
You can use the shared_preload_libraries configuration and _PG_init in your code to run things on server startup. This would allow to preload JWKS on startup which then can be accessed in every backend process. However, as every connection is handled in a separate backend process, you would still need shared memory to update a cache from the backend processes.
I’d also like to start using UUIDv7 — has any progress been made on that so far?
It looks like Percona just released an oauth plugin as well. No idea if it would be useful here but thought I would mention it. https://github.com/Percona-Lab/pg_oidc_validator/.
@mikeywuu The new UUIDv7 function in PG 18 will work now. It does not need any driver support.