Re: [PoC] Federated Authn/z with OAUTHBEARER
От | Wolfgang Walther |
---|---|
Тема | Re: [PoC] Federated Authn/z with OAUTHBEARER |
Дата | |
Msg-id | 18f84e6a-41cf-4313-8bea-6007868dd05a@technowledgy.de обсуждение исходный текст |
Ответ на | Re: [PoC] Federated Authn/z with OAUTHBEARER (Jacob Champion <jacob.champion@enterprisedb.com>) |
Ответы |
Re: [PoC] Federated Authn/z with OAUTHBEARER
Re: [PoC] Federated Authn/z with OAUTHBEARER |
Список | 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 по дате отправления: