Re: [PoC] Federated Authn/z with OAUTHBEARER
От | Jacob Champion |
---|---|
Тема | Re: [PoC] Federated Authn/z with OAUTHBEARER |
Дата | |
Msg-id | CAOYmi+=mGJfJUdz13Ty86-epEX4g9zRNVq0+i+KmHsodAJ2FdQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PoC] Federated Authn/z with OAUTHBEARER (Jacob Champion <jacob.champion@enterprisedb.com>) |
Ответы |
Re: [PoC] Federated Authn/z with OAUTHBEARER
Re: [PoC] Federated Authn/z with OAUTHBEARER |
Список | pgsql-hackers |
On Tue, Apr 8, 2025 at 2:32 PM Jacob Champion <jacob.champion@enterprisedb.com> wrote: > I think the module should be using > libpq's libpq_gettext(). (Which we could do, again through the magic > of dependency injection.) To illustrate what I mean, v3 introduces an initialization function that names the three internal dependencies (libpq_gettext, pg_g_threadlock, and conn->errorMessage) explicitly. I decided not to attempt injecting the variadic libpq_append_conn_error function, and instead focus a level below it, since we must depend directly on libpq_gettext anyway. This is maybe overkill, if it's decided that the two halves must always come from the same build, but I think it should decouple the two sides enough that this is now a question of user experience rather than ABI correctness. Is it acceptable/desirable for a build, which has not been configured --with-libcurl, to still pick up a compatible OAuth implementation installed by the distro? If so, we can go with a "bare" dlopen(). If that's not okay, I think we will probably need to use pkglibdir or some derivative, and introduce a way for tests (and users?) to override that directory selection. Unless someone has a good idea on how we can split the difference. --Jacob
Вложения
В списке pgsql-hackers по дате отправления: