Re: [PoC] Federated Authn/z with OAUTHBEARER

On Tue, 15 Apr 2025 at 19:53, Jacob Champion
<jacob(dot)champion(at)enterprisedb(dot)com> wrote:
> But let me turn this around, because we currently have the opposite
> problem: if someone comes in and adds a completely new feature
> depending on libcurl, and you want OAuth but you do not want that new
> feature -- or vice-versa -- what do you do? In other words, what if
> your concern is not with libcurl, but with the feature itself?

After reconsidering this, I now agree with Peter and Robert that
--with-libcurl is the flag that we should be relying on. Specifically
because of the situation you're describing above: Once you have
libcurl, why wouldn't you want all the features (e.g. in some other
thread there was a suggestion about fetching the PGSERVICEFILE from a
HTTP endpoint).

It's not like we add compile time flags for other user facing features
like --enable-index-scan. All the --enable-xyz options that we have
are for developer features (like debug and asserts). Starting to add
such a flag for this feature seems unnecessary.

Regarding discoverability, I think the error message that you have
already solves that:

> libpq_append_conn_error(conn, "no custom OAuth flows are available, and libpq was not built with libcurl support");

Side-note: I think it would be good to have a different error when
libpq was build with libcurl support, but the dlopen failed. Something
like:

libpq_append_conn_error(conn, "no custom OAuth flows are available,
and libpq-oauth could not be loaded library could not be loaded. Try
installing the libpq-oauth package from the same source that you
installed libpq from");