Re: [PoC] Federated Authn/z with OAUTHBEARER
От | Jacob Champion |
---|---|
Тема | Re: [PoC] Federated Authn/z with OAUTHBEARER |
Дата | |
Msg-id | CAOYmi+n9DHS_xUatuuspdC8tjtaMzY8P11Y9y5Fz+2pjikkL9g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PoC] Federated Authn/z with OAUTHBEARER (Christoph Berg <myon@debian.org>) |
Ответы |
Re: [PoC] Federated Authn/z with OAUTHBEARER
Re: [PoC] Federated Authn/z with OAUTHBEARER |
Список | pgsql-hackers |
On Wed, Apr 9, 2025 at 10:44 AM Christoph Berg <myon@debian.org> wrote: > > Re: Jacob Champion > > > How about ifdef-ing away the dlopen call if --with-libcurl is not specified. > > > > This sounds like a pretty decent, simple way to go. Christoph, does > > that ring any alarm bells from your perspective? > > Ok for me. The opposite that I said in the other mail was just a > suggestion. Cool, thanks! v4 does it that way. It also errors out at configure time if you demand libpq-oauth on a platform that does not support it. The Autoconf side was still polluting LIBS and CPPFLAGS with Curl stuff. I have isolated them in v4, with some additional m4 boilerplate. IMO this makes the subtle difference between USE_LIBCURL (which means the libpq-oauth module is enabled to build) and HAVE_LIBCURL (which means you have libcurl installed locally) even more confusing. Christoph noted that this was also confusing from the packaging side, earlier, and Daniel proposed -Doauth-client/--with-oauth-client as the feature switch name instead. Any objections? Unfortunately it would mean a buildfarm email is in order, so we should get it locked in. Next up: staticlibs. Thanks, --Jacob
Вложения
В списке pgsql-hackers по дате отправления: