public inbox for [email protected]
help / color / mirror / Atom feedFrom: Jacob Champion <[email protected]>
To: PostgreSQL Hackers <[email protected]>
Cc: Christoph Berg <[email protected]>
Cc: Jelte Fennema-Nio <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: Thomas Munro <[email protected]>
Cc: Nazir Bilal Yavuz <[email protected]>
Cc: Antonin Houska <[email protected]>
Cc: Wolfgang Walther <[email protected]>
Cc: Devrim Gündüz <[email protected]>
Cc: Daniel Gustafsson <[email protected]>
Subject: libpq-oauth: a mid-beta naming check
Date: Mon, 4 Aug 2025 16:20:29 -0700
Message-ID: <CAOYmi+m5L=-S8QuZgLcSdHyXreVDCVr2NBbCZVcdVzE8B2y5Xg@mail.gmail.com> (raw)
In-Reply-To: <CAOYmi+mXoq9dUagnkXDgWa72QjCg8SdagBz_yGPUdh1Px0XD5g@mail.gmail.com>
References: <[email protected]>
<CAOYmi+n9DHS_xUatuuspdC8tjtaMzY8P11Y9y5Fz+2pjikkL9g@mail.gmail.com>
<[email protected]>
<CAOYmi+=2cArQoSSRdAYwx2TBSHL5r0UhX28Q-5TP=0g-sxBXCA@mail.gmail.com>
<CAGECzQShbNtypPqabVv2eKJP=0Ejox=6f8k8G1E-2GN6Ag1kAA@mail.gmail.com>
<CAOYmi+=j9nLQFjQ8z0vyQmuhNMwsFbzvne_2S2pTbBGir4q6EQ@mail.gmail.com>
<[email protected]>
<CAOYmi+k9uN2OQ_sXjztZYPSpPbfGmkkv4yhtPhyjNQ6vy7SSfA@mail.gmail.com>
<[email protected]>
<CAOYmi+=WA4ZfyHWt+4=yFV7VAXQWvNKsn4R=3PwLd4GfmSTiBA@mail.gmail.com>
<[email protected]>
<CAOYmi+=cs+gDTAH0L+3JzpRLeHPOXDQxu7MOfsbjah9SkAP_kw@mail.gmail.com>
<CAOYmi+=UsSnLM4K+hYkhrezpQROQ5jr=72feAkQ0Te8GJf3Fbg@mail.gmail.com>
<[email protected]>
<CAOYmi+mXoq9dUagnkXDgWa72QjCg8SdagBz_yGPUdh1Px0XD5g@mail.gmail.com>
On Wed, Apr 30, 2025 at 10:59 AM Jacob Champion
<[email protected]> wrote:
>
> I still see the choice of naming (with its forced-ABI break
> every major version) as needing more scrutiny, and probably worth a
> Revisit entry.
It is now time to revisit.
= The Status Quo =
The libpq-oauth module is loaded on-demand, during the first use of
OAuth authentication, so users who don't want the behavior don't have
to install it. This module is named "libpq-oauth-18.so" for the PG18
release. So libpq v18 will always load the 18 OAuth behavior, libpq
v19 will load the 19 OAuth behavior, etc. Builds on HEAD have already
switched to -19, which is not yet any different from -18.
The internal API injects some libpq internals into the libpq-oauth
module. The ABI for this is assumed to break during each major version
release, so I don't have to watch the boundary like a hawk, and other
maintainers hopefully won't be saddled with breakage reports if I get
hit by a bus. (This is another advantage to using the -MAJOR naming
scheme.) And pg_conn in particular is given more protections: we can
still change its member offsets in minor versions without any ABI
breakage.
During major-version upgrades, if a packager doesn't provide a
side-by-side installation of the -18 and -19 modules, there is a
hazard: an already-loaded v18 libpq might find that the -18 module no
longer exists on disk, which would require a restart of the affected
application to pick up the v19 libpq. This is not really a consequence
of the -MAJOR naming scheme -- it's a consequence of delay-loaded
libraries that go through an ABI version bump -- but the naming scheme
makes the problem extremely visible.
The annoying part is that, if 19 doesn't change anything in the OAuth
flow compared to 18, I will basically have made busywork for our
packagers for no reason. But my goal for v19 is to replace the
internally coupled API with a public API, so that users can swap in
their own flows for use with our utilities. As far as I know, that
work necessarily includes designing a stable ABI and figuring out a
trusted place that users can put their plugins into. If we can do
both, I think we can get rid of the -MAJOR versioning scheme entirely,
because our use case will have been subsumed by the more general
framework.
So, as we approach Beta 3: can anyone think of a way that this plan will fail?
Thanks,
--Jacob
view thread (31+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: libpq-oauth: a mid-beta naming check
In-Reply-To: <CAOYmi+m5L=-S8QuZgLcSdHyXreVDCVr2NBbCZVcdVzE8B2y5Xg@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox