On Thu, Mar 20, 2025 at 2:38 AM Daniel Gustafsson <dan...@yesql.se> wrote:
> > On 19 Mar 2025, at 05:57, Tom Lane <t...@sss.pgh.pa.us> wrote:
> >
> > BTW, I was pretty seriously disheartened just now to realize that
> > this feature was implemented by making libpq depend on libcurl.
> > I'd misread the relevant commit messages to say that libcurl was
> > just being used as test infrastructure; but nope, it's a genuine
> > build and runtime dependency. I wonder how much big-picture
> > thinking went into that.
>
> A considerable amount.
>
> libcurl is not a dependency for OAuth support in libpq, the support was
> designed to be exensible such that clients can hook in their own flow
> implementations. This part does not require libcurl. It is however a
> dependency for the RFC 8628 implementation which is included when building
> with
> --with-libcurl, this in order to ship something which can be used out of the
> box (for actual connections *and* testing) without clients being forced to
> provide their own implementation.
>
> This obviously means that the RFC8628 part could be moved to contrib/, but I
> fear we wouldn't make life easier for packagers by doing that.
How feasible/fragile/weird would it be to dlopen() it on demand?
Looks like it'd take ~20 function pointers:
U curl_easy_cleanup
U curl_easy_escape
U curl_easy_getinfo
U curl_easy_init
U curl_easy_setopt
U curl_easy_strerror
U curl_free
U curl_global_init
U curl_multi_add_handle
U curl_multi_cleanup
U curl_multi_info_read
U curl_multi_init
U curl_multi_remove_handle
U curl_multi_setopt
U curl_multi_socket_action
U curl_multi_socket_all
U curl_multi_strerror
U curl_slist_append
U curl_slist_free_all
U curl_version_info
