MIME-Version: 1.0
References: 
 <CAOYmi+kn+NYA=DNMZds8sPXonAFg3dJnTgQ+vsOMXsk1Yz+3Gg@mail.gmail.com>
 <Z9x_sUXIFz8rjvBN@momjian.us> <1120967.1742504934@sss.pgh.pa.us>
 <wbqaa72xxfnqtsspanbteoycmtpb6oshtwbrm7uwiw3pur4ll4@tybxmaasfjkv>
 <Z-qheTno9lYmjrJu@msg.df7cb.de>
 <CAOYmi+n+WB9fuQeoPL-0FWvC+fzJXUEfH=Ne1q7q5xT936TE=A@mail.gmail.com>
 <CAOYmi+moTsgohh5Tf1gn7dBynARV9EFfWaBVPcJD9O=h6RkSCw@mail.gmail.com>
 <5bec3d4f-613f-425b-88c4-59e71c70f7d6@eisentraut.org>
 <t66lxwxgaxinug7zr4pgf72anhzkqwgrudmqnczgjdu4rv3ll5@jkcxvyvkgcqc>
 <CAOYmi+kc=YXZvZ8YtSPRt57N1Tp9_gRwyXfMO5TJYtCLnEXo1A@mail.gmail.com>
 <Z_QdtqYmSggALamF@msg.df7cb.de>
In-Reply-To: <Z_QdtqYmSggALamF@msg.df7cb.de>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Mon, 7 Apr 2025 14:49:43 -0700
Message-ID: 
 <CAOYmi+=YjmfJ+U6RTHfiXEFt9xJzaHnnbNSgSKahWr774_xGdA@mail.gmail.com>
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
To: Christoph Berg <myon@debian.org>,
 Jacob Champion <jacob.champion@enterprisedb.com>,
	Andres Freund <andres@anarazel.de>, Peter Eisentraut <peter@eisentraut.org>,
 Tom Lane <tgl@sss.pgh.pa.us>,
	Bruce Momjian <bruce@momjian.us>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
	Daniel Gustafsson <daniel@yesql.se>, Thomas Munro <thomas.munro@gmail.com>,
	Nazir Bilal Yavuz <byavuz81@gmail.com>, Antonin Houska <ah@cybertec.at>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAOYmi%2B%3DYjmfJ%2BU6RTHfiXEFt9xJzaHnnbNSgSKahWr774_xGdA%40mail.gmail.com>
Precedence: bulk

On Mon, Apr 7, 2025 at 11:47=E2=80=AFAM Christoph Berg <myon@debian.org> wr=
ote:
> Mmmmh. Since we are currently only talking about 3 symbols, it doesn't
> sound very likely that we'd have to bump this in a major branch.

The ABI extends to the pointers we're using, though. This module uses
PGconn* internals and libpq-int.h. [1]

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

In fact you can't mix and match across different settings of
ENABLE_SSL/GSS/SSPI, either. So I guess that nudges me towards
pkglibdir/<some subdirectory>, to avoid major pain for some unlucky
end user.

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

> The Debian Policy expectation is that everything in libdir is a proper
> library that could be linked to, and that random private stuff should
> be elsewhere. But if being able to use the default lib search path is
> an important argument, we could put it there.

I was hoping the default lib search would make your life (and ours)
easier. If it doesn't, I can lock it down.

Thanks,
--Jacob

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