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+kt5UvPOXXXT9w_nHBNgcqiTQWS2j=D9qJaewvmO4iaAg@mail.gmail.com
Whole thread Raw
In response to Re: [PoC] Federated Authn/z with OAUTHBEARER  (Christoph Berg <myon@debian.org>)
Responses Re: [PoC] Federated Authn/z with OAUTHBEARER
List pgsql-hackers
On Mon, Apr 7, 2025 at 2:58 PM Christoph Berg <myon@debian.org> wrote:
> Why is this module worse? (I guess the answer is internal data
> structures... but does it have to be worse?)

It doesn't have to be, in general, and the coupling surface is small
enough (libpq_append_conn_error) that we have a relatively easy path
toward decoupling it in the future. But for 18, I suspect no one will
be happy with me if I try to turn that inside out right this instant.
The goal was just to turn an internal implementation detail into a
delay-loaded internal implementation detail.

> Because pkglibdir would be something like /usr/lib/postgresql/17/lib,
> even when there is only one libpq5 package for all major server
> versions on Debian. So if you have postgresql-16 installed, you'd end
> up with
>
> /usr/lib/postgresql/16/{bin,lib}  everything from PG 16
> /usr/lib/x86_64-linux-gnu/libpq*  libpq5
> /usr/lib/postgresql/17/lib/libpq-oauth.so
>
> ... which is weird.

Weird, sure -- but it's correct, right? Because you have PG17's OAuth
flow installed.

If someone comes to the list with a flow bug in three years, and I ask
them what version they have installed, and they tell me "PG16, and
it's loading /usr/lib/aarch64-linux-gnu/libpq/libpq-oauth.so." That
won't be incredibly helpful IMHO.

> > [1] Future work ideas in this area include allowing other people to
> > compile their own loadable flow plugin, so that the utilities can use
> > it. (Only Device Authorization can be used by psql et al, for 18.) At
> > that point, developers will need a limited API to twiddle the
> > connection handle, and our builtin flow(s?) could use the same API.
> > But that's not work we can tackle for 18.
>
> Perhaps keep things simple for PG18 and choose a simple filename and
> location. If future extensions need something more elaborate, we can
> still switch later.

Sounds good. Any opinions from the gallery on what a "libpq plugin
subdirectory" in pkglibdir should be called? ("client", "modules",
"plugins"...?) Is there still a good reason to put any explicit
versioning into the filename if we do that?

Thanks,
--Jacob



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Horribly slow pg_upgrade performance with many Large Objects
Next
From: James Hunter
Date:
Subject: Re: Proposal: "query_work_mem" GUC, to distribute working memory to the query's individual operators