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

From Jacob Champion
Subject Re: [PoC] Federated Authn/z with OAUTHBEARER
Date
Msg-id CAOYmi+nQapg91WVfb06uL02UEisPBejQd4sOC3G77aKqsnE7KQ@mail.gmail.com
Whole thread Raw
In response to Re: [PoC] Federated Authn/z with OAUTHBEARER  (Christoph Berg <myon@debian.org>)
Responses Re: [PoC] Federated Authn/z with OAUTHBEARER
List 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 by date:

Previous
From: Amit Langote
Date:
Subject: Re: Partition pruning on parameters grouped into an array does not prune properly
Next
From: Ranier Vilela
Date:
Subject: Possible api miuse bms_next_member