Re: [PoC] Federated Authn/z with OAUTHBEARER - Mailing list pgsql-hackers

From Jelte Fennema-Nio
Subject Re: [PoC] Federated Authn/z with OAUTHBEARER
Date
Msg-id CAGECzQSYZhX2AW2gn0dmOGfoUp18z1EMkVm1enxsfTxJFqJviQ@mail.gmail.com
Whole thread Raw
In response to Re: [PoC] Federated Authn/z with OAUTHBEARER  (Jacob Champion <jacob.champion@enterprisedb.com>)
List pgsql-hackers
On Wed, Apr 9, 2025, 10:58 Jacob Champion <jacob.champion@enterprisedb.com> wrote:
Is it acceptable/desirable for a build, which has not been configured
--with-libcurl, to still pick up a compatible OAuth implementation
installed by the distro? If so, we can go with a "bare" dlopen(). If
that's not okay, I think we will probably need to use pkglibdir or
some derivative, and introduce a way for tests (and users?) to
override that directory selection. Unless someone has a good idea on
how we can split the difference.

That seems like it could cause some confusing situations and also making local testing of different compilation options difficult. How about ifdef-ing away the dlopen call if --with-libcurl is not specified. So to have oauth support you need to compile libpq with --with-libcurl AND the libpq-oauth.so file needs to be present. 

(resent because I failed to reply to all from my phone) 

pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: tab complete for COPY populated materialized view TO
Next
From: Laurenz Albe
Date:
Subject: Re: [PATCH] New predefined role pg_manage_extensions