Re: [PoC] Federated Authn/z with OAUTHBEARER - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: [PoC] Federated Authn/z with OAUTHBEARER
Date
Msg-id CAOYmi+nGXWDtzZVe+f1-tiq__M1GjHV+nyS6=wVsjCZ3XU4V8A@mail.gmail.com
Whole thread Raw
In response to Re: [PoC] Federated Authn/z with OAUTHBEARER  (Jacob Champion <jacob.champion@enterprisedb.com>)
List pgsql-hackers
On Tue, Apr 8, 2025 at 10:36 AM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> Yeah, but it's one of those things that feels like it must have been
> solved by the others in the space. Once it's installed, the concern
> goes away (unless you demand absolute relocatability without
> recompilation). I'll take a look at how libkrb/libmagick do their
> testing.

Perhaps unsurprisingly, they inject different lookup paths via
envvars. We could do the same (I have FUD about the security
characteristics)...

> If it somehow turns out to be impossible, one option might be to shove
> a more detailed ABI identifier into the name.

...but I wonder if I can invert the dependency on
libpq_append_conn_error entirely, and remove that part of the ABI
surface, then revisit the discussion on `-<major>.so` vs
`-<major>-<minor>.so`.

--Jacob



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Horribly slow pg_upgrade performance with many Large Objects
Next
From: Jacob Champion
Date:
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER