MIME-Version: 1.0
References: <CAN4CZFM3b8u5uNNNsY6XCya257u+Dofms3su9f11iMCxvCacag@mail.gmail.com>
 <CAE2r8H55geNFtECuFunpgn0LJK2+rntGuTeqNr6mP7gGhWFRbA@mail.gmail.com>
 <CAN4CZFP_2fe2-18wUoXDZodV8suVe9o++pv=hP8KxxvWkmCx7A@mail.gmail.com>
 <CAOYmi+kMuA7t9ao6rWZ=5kn_Zmd7qtwOay_ocEBXwkzKWbefhQ@mail.gmail.com>
 <CAE2r8H439jg+e5gXJpNNMoroe4CfWauDRfUBZC_9NUNTOhqzBQ@mail.gmail.com>
 <CAN4CZFN9RMF_79kx75SkQZezd91DocUzz89bJeBJrMO=uNuG2w@mail.gmail.com>
 <CAOYmi+krPZDC8K+9z64M2EY9fELTKzLbqw8fD_wK=87YV+TBgw@mail.gmail.com>
 <CAN4CZFPvjAt+eZJd=Rxp=yXRjva8CpJ_BbnF=vQW6uXCqfrjEg@mail.gmail.com>
 <CAOYmi+nbCrvcE9wLQdNCgMwDbbi_UzGYrzfC54txmMBJ9KxO=Q@mail.gmail.com>
 <CAN4CZFNywvG59B+nBgD1_1fHE2uODBH3EcF_gwLmC7Y5U6Ru4Q@mail.gmail.com>
 <CAOYmi+=-OdzHMzqg9i8TwYvgKwE-vroj0d-9SqnRnwbz02SgTg@mail.gmail.com>
 <CAN4CZFPo1POb9fWMihTACFxE=xSxKEANHRkxN4YbMMN-0SML=w@mail.gmail.com>
 <CAOYmi+kVAiKf=WrnyzGxCmx-uu=arPE0=+Mf_AOhuTzkvCNC2w@mail.gmail.com>
 <CAN4CZFMeTuH4uANV1bOox0d-1mycCnyghY49cL+E8PYZ4Y=0Kw@mail.gmail.com>
 <CAOYmi+nKQ_7+pWSzw=rP2_T9UL=URHBsKq005BDeMmmC_=PV8g@mail.gmail.com>
 <CAN4CZFM8TgqDi=5Bot2imtd2heGESjpMfQ7kW4qeFSjO7NTAQQ@mail.gmail.com>
 <CAOYmi+kVCWCbf+yjmFSeddmqxgYTO5vU+CqwFq6EbpyLkpW=Bw@mail.gmail.com> <CAN4CZFNt3WVPsORSFfdZo3nYn9Fa1-CkKKdu3_gVNpw4jbenjg@mail.gmail.com>
In-Reply-To: <CAN4CZFNt3WVPsORSFfdZo3nYn9Fa1-CkKKdu3_gVNpw4jbenjg@mail.gmail.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Tue, 20 Jan 2026 10:02:16 -0800
Message-ID: <CAOYmi+n9+VDNayxsZuG30YLxOXrVB2Wu=jBR4WrEdJvxjTATKw@mail.gmail.com>
Subject: Re: Custom oauth validator options
To: Zsolt Parragi <zsolt.parragi@percona.com>
Cc: VASUKI M <vasukianand0119@gmail.com>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, david.g.johnston@gmail.com, 
	Robert Haas <robertmhaas@gmail.com>, myon@debian.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAOYmi%2Bn9%2BVDNayxsZuG30YLxOXrVB2Wu%3DjBR4WrEdJvxjTATKw%40mail.gmail.com>
Precedence: bulk

On Mon, Jan 19, 2026 at 12:30=E2=80=AFPM Zsolt Parragi
<zsolt.parragi@percona.com> wrote:
> This is again a bit of a different topic, but I could make that a
> proper patch from this prototype.

Let's separate the "verify session-preloaded GUCs" question from this
feature request, yeah.

> The important part for this thread is that if you would prefer a
> version which completely verifies the pg_hba configuration before
> accepting it, it's not that difficult to implement, or at least it's
> not as complex as I originally imagined it. But even that won't
> guarantee that the configuration always remains valid, because session
> preload libraries can change without a server restart/reload... but
> that's a rare corner case, and it could be a useful check most of the
> time.

Right. I've been thinking about strategy here, and I'm not sure I've
solidified my thoughts yet, but I don't want to make you wait for
that. So here goes:

The inability to verify the HBA settings, without actively loading the
extension, is a drawback whether we introduce a PGC_HBA or not. I feel
pretty strongly that we can't require shared_preload_libraries for
this use case. And given the choice between "you cannot modify per-HBA
settings at all" and "we can't tell you until you test them whether
they're valid or not", most people would probably prefer the latter
limitation. Especially since the *values* for many existing HBA
parameters cannot truly be "validated" without testing anyway;
consider ldapserver etc.

Since session_preload_libraries already can't do this, I don't feel
too bad about us not doing it for a first version of the feature, but
this limitation is likely to remain for a long time. Unless you think
that there's a technical solution where the benefit easily outweighs
the maintenance cost. And my guess is that this conversation is about
to collide at high speed with the Postgres-threading work that's in
progress.

I like the idea of a PGC_HBA. I think it makes a lot of sense to be
able set other GUC overrides here -- authentication_timeout,
log_connections, pre/post_auth_delay. It seems architectually sound
and generically useful.

I'm worried that it's about to make a different decision from the
decision that is being made for the pg_hosts.conf file for SNI. So
this is not going to feel cohesive at first, and that's only "okay" if
it becomes cohesive very quickly, which requires a larger audience.

I'm also worried about namespace collisions between GUC and HBA. If we
scope it to OAuth then that becomes easier (e.g. just prepend
`validator.` or something to the setting name in HBA and then it's
obvious what's going on). But if someone decides in PG20 that
pam_use_hostname is a good GUC name for something, we're in trouble,
because the existing HBA options do not plug into the GUC system.

That's a lot of risk. High revert potential without multiple
maintainers saying "yes", IMO, and if that happens we will have no
improvement here for PG19.

So,
1) how close to the sun do you feel like flying today?
2) do you agree with the above?
3) can your option (b) or (c) make enough use of existing GUC
infrastructure, so that a future PGC_HBA could easily subsume an
OAuth-specific solution, if people want to continue down that path in
a less OAuth-centric thread?

--Jacob