Re: [PoC] Federated Authn/z with OAUTHBEARER

Re: Jacob Champion
> > Putting the minor version into the filename would make looking at
> > package diffs harder when upgrading. Do we really need this as opposed
> > to some hardcoded number like libpq.so.5.18 ?
> >
> > Perhaps reusing the number from libpq.so.5.18 also for this lib would
> > be the way to go?
>
> That doesn't address Andres' concern, though; if multiple
> installations all use libpq.so.5.18, they still can't necessarily mix
> and match.

Well the whole world is linking against libpq5.so and not breaking
either. Why is this module worse? (I guess the answer is internal data
structures... but does it have to be worse?)

> > Though for Debian, I'd actually prefer
> > /usr/lib/$DEB_HOST_MULTIARCH/libpq/libpq-oauth...
> > since the libpq packaging is independent from the major version
> > packaging.
>
> Not sure I understand this. Do you mean you'd patch our lookup for
> Debian, to find it there instead of pkglibdir? I don't think we can
> adopt that ourselves, for the same reasons as above; the two sides
> have to be in lockstep.

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.

> [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.

Christoph