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

From Wolfgang Walther
Subject Re: [PoC] Federated Authn/z with OAUTHBEARER
Date
Msg-id 18f84e6a-41cf-4313-8bea-6007868dd05a@technowledgy.de
Whole thread Raw
In response to Re: [PoC] Federated Authn/z with OAUTHBEARER  (Jacob Champion <jacob.champion@enterprisedb.com>)
Responses Re: [PoC] Federated Authn/z with OAUTHBEARER
Re: [PoC] Federated Authn/z with OAUTHBEARER
List pgsql-hackers
Jacob Champion:
> On Tue, Apr 8, 2025 at 9:32 AM Wolfgang Walther <walther@technowledgy.de> wrote:
>> And that should also not be a problem for distributions - they could offer a libpq and a libpq_oauth package, where
onlyone of them can be installed at the same time, I guess? *
 
> My outsider understanding is that maintaining this sort of thing
> becomes a major headache, because of combinatorics. You don't really
> want to ship a libpq and libpq-with-gss and libpq-with-oauth and
> libpq-with-oauth-and-gss and ...

That would only be the case, if you were to consider those other 
dependencies as "dangerous" as cURL. But we already depend on them. So 
if it's really the case that cURL is that much worse, that we consider 
loading it as a module... then the combinatorics should not be a problem 
either.

However, if the other deps are considered problematic as well, then the 
ship has already sailed, and there is not point for a special case here 
anymore.

Best,

Wolfgang




pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Horribly slow pg_upgrade performance with many Large Objects
Next
From: Jacob Champion
Date:
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER