Re: [PoC] Federated Authn/z with OAUTHBEARER

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. I can see at least two objections:

* This represents a pretty large expansion of dependency footprint,
not just for us but for the umpteen hundred packages that depend on
libpq. libcurl alone maybe wouldn't be so bad, but have you looked
at libcurl's dependencies? On RHEL8,

$ ldd /usr/lib64/libcurl.so.4.5.0
linux-vdso.so.1 (0x00007fffd3075000)
libnghttp2.so.14 => /lib64/libnghttp2.so.14 (0x00007f992097a000)
libidn2.so.0 => /lib64/libidn2.so.0 (0x00007f992075c000)
libssh.so.4 => /lib64/libssh.so.4 (0x00007f99204ec000)
libpsl.so.5 => /lib64/libpsl.so.5 (0x00007f99202db000)
libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007f9920046000)
libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f991fb5b000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f991f906000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f991f61b000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f991f404000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f991f200000)
libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x00007f991efb1000)
liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x00007f991eda1000)
libbrotlidec.so.1 => /lib64/libbrotlidec.so.1 (0x00007f991eb94000)
libz.so.1 => /lib64/libz.so.1 (0x00007f991e97c000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f991e75c000)
libc.so.6 => /lib64/libc.so.6 (0x00007f991e386000)
libunistring.so.2 => /lib64/libunistring.so.2 (0x00007f991e005000)
librt.so.1 => /lib64/librt.so.1 (0x00007f991ddfd000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9920e30000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f991dbf9000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f991d9e8000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f991d7e4000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f991d5cc000)
libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007f991d3ae000)
libm.so.6 => /lib64/libm.so.6 (0x00007f991d02c000)
libbrotlicommon.so.1 => /lib64/libbrotlicommon.so.1 (0x00007f991ce0b000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f991cbe0000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f991c9b7000)
libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f991c733000)

* Given libcurl's very squishy portfolio:

libcurl is a free and easy-to-use client-side URL transfer library, supporting
FTP, FTPS, HTTP, HTTPS, SCP, SFTP, TFTP, TELNET, DICT, LDAP, LDAPS, FILE, IMAP,
SMTP, POP3 and RTSP. libcurl supports SSL certificates, HTTP POST, HTTP PUT,
FTP uploading, HTTP form based upload, proxies, cookies, user+password
authentication (Basic, Digest, NTLM, Negotiate, Kerberos4), file transfer
resume, http proxy tunneling and more.

it's not exactly hard to imagine them growing a desire to handle
"postgresql://" URLs, which they would surely do by invoking libpq.
Then we'll have circular build dependencies and circular runtime
dependencies, not to mention inter-library recursion at runtime.

This is not quite a hill that I wish to die on, but I will
flatly predict that we will regret this.

regards, tom lane