Re: [oauth] Stabilize the libpq-oauth ABI (and allow alternative implementations?)

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
Cc: "Jonathan Gonzalez V(dot)" <jonathan(dot)abdiel(at)gmail(dot)com>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [oauth] Stabilize the libpq-oauth ABI (and allow alternative implementations?)
Date: 2026-03-31 18:50:02
Message-ID: CAOYmi+=78NhN+6K-p15Q6vJWYCvsuQtB5swM7g6wRn+gBWU0eA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 16, 2026 at 12:33 AM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
> I think this check relies on that when poisoning, request->error should be NULL. So, does it make sense to Assert(request->error==NULL) in the poison branch?

Yes, that's a good idea. Done in the committed version.

> 2 - 0002 Overall LGTM. A small comment is that, now use_builtin_flow() becomes a bit misleading because it may turn to non-builtin when libpq_oauth_init is not provided by the lib. So, maybe rename the function to something like try_builtin_flow()?

I think you're correct that the naming here has not caught up to where
we are, but try_builtin_flow() doesn't get us much closer in my
opinion, and I wasn't able to find something I really liked. This will
need a refactor when plugins arrive, so I'm deferring for now.

Thanks!
--Jacob

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2026-03-31 18:51:14 Re: [oauth] Stabilize the libpq-oauth ABI (and allow alternative implementations?)
Previous Message Andres Freund 2026-03-31 18:49:19 Re: Don't synchronously wait for already-in-progress IO in read stream