Re: [PoC] Federated Authn/z with OAUTHBEARER - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PoC] Federated Authn/z with OAUTHBEARER
Date
Msg-id 814794.1742418239@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PoC] Federated Authn/z with OAUTHBEARER  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: [PoC] Federated Authn/z with OAUTHBEARER
List pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes:
> On Thu, Mar 20, 2025 at 2:38 AM Daniel Gustafsson <daniel@yesql.se> wrote:
>> On 19 Mar 2025, at 05:57, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> BTW, I was pretty seriously disheartened just now to realize that
>>> this feature was implemented by making libpq depend on libcurl.

> How feasible/fragile/weird would it be to dlopen() it on demand?

FWIW, that would not really move the needle one bit so far as
my worries are concerned.  What I'm unhappy about is the very
sizable expansion of our build dependency footprint as well
as the sizable expansion of the 'package requires' footprint.
The fact that the new dependencies are mostly indirect doesn't
soften that blow at all.

To address that (without finding some less kitchen-sink-y OAuth
implementation to depend on), we'd need to shove the whole thing
into a separately-built, separately-installable package.

What I expect is likely to happen is that packagers will try to do
that themselves to avoid the dependency bloat.  AFAICT our current
setup will make that quite painful for them, and in any case I
don't believe it's work we should make them do.  If they fail to
do that, the burden of the extra dependencies will fall on end
users.  Either way, it's not going to make us look good.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Sami Imseih
Date:
Subject: Re: making EXPLAIN extensible
Next
From: Peter Geoghegan
Date:
Subject: Re: Adding skip scan (including MDAM style range skip scan) to nbtree