public inbox for [email protected]  
help / color / mirror / Atom feed
From: Jacob Champion <[email protected]>
To: Zsolt Parragi <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Chao Li <[email protected]>
Subject: Re: [oauth] Stabilize the libpq-oauth ABI (and allow alternative implementations?)
Date: Fri, 6 Mar 2026 16:27:12 -0800
Message-ID: <CAOYmi+mLaohk3FLbH9fKGmzN7yFGHs2Zefdyp31wbL1130puiA@mail.gmail.com> (raw)
In-Reply-To: <CAN4CZFOMv=0Y1PZ8uw3xgJmEqt4D1dr1-yOq9jjZYTARZp7H9Q@mail.gmail.com>
References: <CAOYmi+mrGg+n_X2MOLgeWcj3v_M00gR8uz_D7mM8z=dX1JYVbg@mail.gmail.com>
	<[email protected]>
	<CAOYmi+mwzS4xfgomL1Lte+W1hRk+zahhZLnRMDJ8nYxoHUWt_w@mail.gmail.com>
	<CAOYmi+mEU_q9sr1PMmE-4rLwFN=OjyndDwFZvpsMU3RNJLrM9g@mail.gmail.com>
	<CAN4CZFPwdH_GMrappThju=t4m5n95Dse6ecTNwN=h4GpZLOMng@mail.gmail.com>
	<CAOYmi+m-hphbx=CRfGSdcrHi-jL3OrZGJMTAPOYp=OK253hBTA@mail.gmail.com>
	<CAOYmi+nnYr_Oe=KH2ZW6Ld88eZWv5P-s5ZtWOEh2KsPtMqOzbg@mail.gmail.com>
	<CAOYmi+nCg5upBVOo_UCSjMfO=YMkZXcSEsgaADKXqerr5wahZQ@mail.gmail.com>
	<CAOYmi+nRmt+K+ZVNztKFv=LuasDCCSsXLihZB6BEkVeroW8EvA@mail.gmail.com>
	<CAN4CZFOMv=0Y1PZ8uw3xgJmEqt4D1dr1-yOq9jjZYTARZp7H9Q@mail.gmail.com>

On Fri, Mar 6, 2026 at 2:44 PM Zsolt Parragi <[email protected]> wrote:
> + if ((start_flow = dlsym(state->flow_module, "pg_start_oauthbearer")) == NULL)
>
> And this path has the same issue, the library is there, so suggesting
> to install libpq-oauth isn't helpful.

I'll cherry-pick some of the -1 handling backwards in the patchset to
handle this.

> + appendPQExpBuffer(&conn->errorMessage,
> +   "use_builtin_flow: failed to lock mutex (%d)\n",
> +   lockerr);
>
> This is after an assert, so maybe it is okay as is, but this bypasses
> gettext.

Correct. For PG18, I got the feedback that can't-happen errors in
OAuth should really remain untranslated, unless it's clear that the
user can act on them. Otherwise we're consuming translators' time for
no practical benefit.

> > (try installing the libpq-oauth package)
>
> This isn't changed in these patches, but Is it okay to assume a
> package name here?

No, not really, but see [1]. Any "vanilla" version of that error
message will contain the string "libpq-oauth" regardless; that's the
module's name. So package maintainers need to either patch the line if
it's not useful, or else let us know how they'd prefer to override
this -- Makefile? Configure? (Meson?) -- to improve the situation.
Christoph gave the most feedback here, so Debian has the most-greased
wheel at the moment. :D

Thanks,
--Jacob

[1] https://postgr.es/m/aAOREVWMFTuWvJ1l%40msg.df7cb.de





view thread (19+ 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]
  Subject: Re: [oauth] Stabilize the libpq-oauth ABI (and allow alternative implementations?)
  In-Reply-To: <CAOYmi+mLaohk3FLbH9fKGmzN7yFGHs2Zefdyp31wbL1130puiA@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