Re: [PoC] Federated Authn/z with OAUTHBEARER - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: [PoC] Federated Authn/z with OAUTHBEARER
Date
Msg-id CAOYmi+kn0_FioLpDqctn97a_W8n90XLt_OmU1xL6ZdK8DP8ufA@mail.gmail.com
Whole thread Raw
In response to Re: [PoC] Federated Authn/z with OAUTHBEARER  (Peter Eisentraut <peter@eisentraut.org>)
List pgsql-hackers
On Wed, Jan 8, 2025 at 11:37 AM Peter Eisentraut <peter@eisentraut.org> wrote:
> I don't know what you mean by
> "accept in the code".  I would agree with "tolerate some inconsistency"
> in the code but not with, like, create alias names for all the interface
> names.

"Tolerate inconsistency" was what I had in mind. So I'll plan to do a
pass on the user documentation, but not a search-and-replace in the
code at this point.

> > It'd also couple clients against libpq-int.h, so they'd have to
> > remember to recompile every release. I'm worried that'd cause a bunch
> > of ABI problems...
>
> Couldn't that function use PQsocket() to get at the actual socket from
> the PGconn handle?

It's an output parameter (i.e. the async callback is responsible for
setting conn->altsock). Unless I've missed the point entirely, I don't
think PQsocket() helps here.

> >      warning C4715: 'fail_token': not all control paths return a value
> >
> > Is that expected?
>
> Ah yes, because MSVC doesn't support the noreturn attribute.  (See
> <https://www.postgresql.org/message-id/flat/pxr5b3z7jmkpenssra5zroxi7qzzp6eswuggokw64axmdixpnk%40zbwxuq7gbbcw>.)
>   So ok to leave as you had it for now.

Will do.

Thanks!
--Jacob



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: use a non-locking initial test in TAS_SPIN on AArch64
Next
From: Nathan Bossart
Date:
Subject: Re: use a non-locking initial test in TAS_SPIN on AArch64