From: | Wolfgang Walther <walther(at)technowledgy(dot)de> |
---|---|
To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Christoph Berg <myon(at)debian(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>, Antonin Houska <ah(at)cybertec(dot)at> |
Subject: | Re: [PoC] Federated Authn/z with OAUTHBEARER |
Date: | 2025-04-08 16:57:18 |
Message-ID: | 18f84e6a-41cf-4313-8bea-6007868dd05a@technowledgy.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jacob Champion:
> On Tue, Apr 8, 2025 at 9:32 AM Wolfgang Walther <walther(at)technowledgy(dot)de> wrote:
>> And that should also not be a problem for distributions - they could offer a libpq and a libpq_oauth package, where only one 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jacob Champion | 2025-04-08 17:00:56 | Re: [PoC] Federated Authn/z with OAUTHBEARER |
Previous Message | Hannu Krosing | 2025-04-08 16:52:45 | Re: Horribly slow pg_upgrade performance with many Large Objects |