On Wed, Mar 19, 2025 at 02:38:08PM +0100, Daniel Gustafsson wrote:
> > On 19 Mar 2025, at 05:57, Tom Lane <tgl@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.
I see it now ---- without having RFC 8628 built into the server, clients
have to implement it. Do we know what percentage would need to do that?
The spec:
https://datatracker.ietf.org/doc/html/rfc8628
Do we think packagers will use the --with-libcurl configure option?
It does kind of make sense for curl to handle OAUTH since curl has to
simulate a browser. I assume we can't call a shell to invoke curl from
the command line.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
