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

From Jacob Champion
Subject Re: [oauth] Stabilize the libpq-oauth ABI (and allow alternative implementations?)
Date
Msg-id CAOYmi+=78NhN+6K-p15Q6vJWYCvsuQtB5swM7g6wRn+gBWU0eA@mail.gmail.com
Whole thread
In response to Re: [oauth] Stabilize the libpq-oauth ABI (and allow alternative implementations?)  (Chao Li <li.evan.chao@gmail.com>)
List pgsql-hackers
On Mon, Mar 16, 2026 at 12:33 AM Chao Li <li.evan.chao@gmail.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
tonon-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



pgsql-hackers by date:

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