Re: [PoC] Federated Authn/z with OAUTHBEARER
От | Jacob Champion |
---|---|
Тема | Re: [PoC] Federated Authn/z with OAUTHBEARER |
Дата | |
Msg-id | CAOYmi+nQapg91WVfb06uL02UEisPBejQd4sOC3G77aKqsnE7KQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PoC] Federated Authn/z with OAUTHBEARER (Christoph Berg <myon@debian.org>) |
Ответы |
Re: [PoC] Federated Authn/z with OAUTHBEARER
|
Список | pgsql-hackers |
On Wed, Apr 9, 2025 at 1:14 AM Christoph Berg <myon@debian.org> wrote: > One design goal could be reproducible builds-alike, that is, have > libpq configured with or without libcurl be completely identical, and > the feature being present is simply the libpq-oauth.so file existing > or not. That might make using plain dlopen() more attractive. I think that's more or less what the current v3 does, but Jelte's point (which is upthread for me but downthread for others :D) is that making them identical might not actually be a desirable thing in this situation, because if you don't compile --with-libcurl, when you test that the feature is disabled you might potentially find that it is not. On Wed, Apr 9, 2025 at 1:39 AM Jelte Fennema-Nio <postgres@jeltef.nl> wrote: > 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? Thanks, --Jacob
В списке pgsql-hackers по дате отправления: