From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
---|---|
To: | Christoph Berg <myon(at)debian(dot)org>, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>, Antonin Houska <ah(at)cybertec(dot)at> |
Subject: | Re: [PoC] Federated Authn/z with OAUTHBEARER |
Date: | 2025-04-07 22:26:47 |
Message-ID: | CAOYmi+kt5UvPOXXXT9w_nHBNgcqiTQWS2j=D9qJaewvmO4iaAg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Apr 7, 2025 at 2:58 PM Christoph Berg <myon(at)debian(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | James Hunter | 2025-04-07 22:36:59 | Re: Proposal: "query_work_mem" GUC, to distribute working memory to the query's individual operators |
Previous Message | Nathan Bossart | 2025-04-07 22:17:03 | Re: Horribly slow pg_upgrade performance with many Large Objects |