Re: pgsql: Add support for OAUTHBEARER SASL mechanism
Jacob Champion <jacob.champion@enterprisedb.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
To: Daniel Gustafsson <daniel@yesql.se>,
Peter Eisentraut <peter@eisentraut.org>
Cc: Christoph Berg <myon@debian.org>, Thomas Munro <thomas.munro@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-04-01T15:48:52Z
Lists: pgsql-hackers
On Tue, Apr 1, 2025 at 6:12 AM Daniel Gustafsson <daniel@yesql.se> wrote: > > > On 1 Apr 2025, at 15:03, Christoph Berg <myon@debian.org> wrote: > > > With the libpq-oauth split, this makes even more sense because > > building a library that always throws an error isn't very useful. > > (Don't build that file at all if the feature doesn't work.) > > After the split, configure/meson should fail if the libcurl dependency isn't > satisfied or if the platform isn't supported. Yeah, after sleeping on it I agree. If I want a "canary" buildfarm animal to opt into compilation on unsupported platforms, I can instead look into a manual #define or something; it doesn't have to be a supported configure-time thing. > > Since oauth/curl have some security implications, would it make more > > sense to call the switch --enable-oauth (-Doauth) so users could > > control better what features their libpq is going to have? Perhaps > > some other feature (pg_service as URL?) is going to need libcurl as > > well, but it should be configurable separately. > > Perhaps --with-oauth-client for the opt-in libpq-oauth? It started as -Doauth way back when, but was changed as part of the discussion at [1]. Peter, do you have any objections to switching back to an OAuth-related name? --Jacob [1] https://postgr.es/m/6bde5f56-9e7a-4148-b81c-eb6532cb3651%40eisentraut.org
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
oauth: Fix build on platforms without epoll/kqueue
- 8ae0a37932d8 18.0 landed
-
Add support for OAUTHBEARER SASL mechanism
- b3f0be788afc 18.0 cited