On Tue, 15 Apr 2025 at 19:53, Jacob Champion <jacob.champ...@enterprisedb.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");
