Re: [PoC] Federated Authn/z with OAUTHBEARER
От | Thomas Munro |
---|---|
Тема | Re: [PoC] Federated Authn/z with OAUTHBEARER |
Дата | |
Msg-id | CA+hUKGJpWwVubuiOzcU4xM88r-8Lu0Ht_oXDtdw9qUHPgTxY9w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PoC] Federated Authn/z with OAUTHBEARER (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PoC] Federated Authn/z with OAUTHBEARER
Re: [PoC] Federated Authn/z with OAUTHBEARER |
Список | pgsql-hackers |
On Thu, Mar 20, 2025 at 10:04 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Thomas Munro <thomas.munro@gmail.com> writes: > > How feasible/fragile/weird would it be to dlopen() it on demand? > > FWIW, that would not really move the needle one bit so far as > my worries are concerned. What I'm unhappy about is the very > sizable expansion of our build dependency footprint as well > as the sizable expansion of the 'package requires' footprint. > The fact that the new dependencies are mostly indirect doesn't > soften that blow at all. > > To address that (without finding some less kitchen-sink-y OAuth > implementation to depend on), we'd need to shove the whole thing > into a separately-built, separately-installable package. > > What I expect is likely to happen is that packagers will try to do > that themselves to avoid the dependency bloat. AFAICT our current > setup will make that quite painful for them, and in any case I > don't believe it's work we should make them do. If they fail to > do that, the burden of the extra dependencies will fall on end > users. Either way, it's not going to make us look good. It would increase the build dependencies, assuming a package maintainer wants to enable as many features as possible, but it would *not* increase the 'package requires' footprint, merely the 'package suggests' footprint (as Debian calls it), and it's up to the user whether they install suggested extra packages, no?
В списке pgsql-hackers по дате отправления: