Re: [PoC] Federated Authn/z with OAUTHBEARER
От | Daniel Gustafsson |
---|---|
Тема | Re: [PoC] Federated Authn/z with OAUTHBEARER |
Дата | |
Msg-id | 1BBF3A55-15BF-409C-9BBE-E6A554A84915@yesql.se обсуждение исходный текст |
Ответ на | Re: [PoC] Federated Authn/z with OAUTHBEARER (Jacob Champion <jacob.champion@enterprisedb.com>) |
Список | pgsql-hackers |
> On 21 Nov 2024, at 19:51, Jacob Champion <jacob.champion@enterprisedb.com> wrote: > > On Tue, Nov 19, 2024 at 3:05 AM Peter Eisentraut <peter@eisentraut.org> wrote: >> Personally, I'm not even a fan of the -Dssl/--with-ssl system. I'm more >> attached to --with-openssl. In hindsight, --with-ssl was prematurely pulled out from the various TLS backend patchsets that were proposed a while back. I wonder if we should reword "Obsolete equivalent of --with-ssl=openssl" in the docs with plain "Equivalent of ..". (which is really for another thread.) >> But if you want to stick with that, a more >> suitable naming would be something like, say, --with-httplib=curl, which >> means, use curl for all your http needs. Because if we later add other >> functionality that can use some http, I don't think we want to enable or >> disable them all individually, or even mix different http libraries for >> different features. In practice, curl is a widely available and >> respected library, so I'd expect packagers to be just turn it all on >> without much further consideration. > > Okay, I can see that. I'll work on replacing --with-builtin-oauth. Any > votes from the gallery on --with-httplib vs. --with-libcurl? I think I would vote for --with-libcurl. -- Daniel Gustafsson
В списке pgsql-hackers по дате отправления: