Re: [PoC] Federated Authn/z with OAUTHBEARER
От | Thomas Munro |
---|---|
Тема | Re: [PoC] Federated Authn/z with OAUTHBEARER |
Дата | |
Msg-id | CA+hUKG+Wb3E5arfwpFjbRxSGoUcVWWFVXUzHSMSGmiRpBerA1Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PoC] Federated Authn/z with OAUTHBEARER (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PoC] Federated Authn/z with OAUTHBEARER
|
Список | pgsql-hackers |
On Thu, Mar 20, 2025 at 11:19 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Thomas Munro <thomas.munro@gmail.com> writes: > > 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? > > Maybe I'm confused, but what I saw was a hard dependency on libcurl, > as well as several of its dependencies: > I don't think that will be satisfied by 'package suggests'. > Even if it somehow manages to load, the result of trying to > use OAuth would be a segfault rather than any useful message. I was imagining that it would just error out if you try to use that stuff and it fails to open libcurl. Then it's up to end users: if they want to use libpq + OAuth, they have to install both libpq5 and libcurl packages, and if they don't their connections will just fail, presumably with some error message explaining why. Or something like that...
В списке pgsql-hackers по дате отправления: