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> <CAOYmi+n9+VDNayxsZuG30YLxOXrVB2Wu=jBR4WrEdJvxjTATKw@mail.gmail.com>
In-Reply-To: <CAOYmi+n9+VDNayxsZuG30YLxOXrVB2Wu=jBR4WrEdJvxjTATKw@mail.gmail.com>
From: Zsolt Parragi <zsolt.parragi@percona.com>
Date: Tue, 20 Jan 2026 20:31:11 +0000
Message-ID: <CAN4CZFP2N=+bqJL7PUiy0DR0dGwbdd1Na0rdMCpzdpaH50O87w@mail.gmail.com>
Subject: Re: Custom oauth validator options
To: Jacob Champion <jacob.champion@enterprisedb.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"
Archived-At: <https://www.postgresql.org/message-id/CAN4CZFP2N%3D%2BbqJL7PUiy0DR0dGwbdd1Na0rdMCpzdpaH50O87w%40mail.gmail.com>
Precedence: bulk

> I'm not sure I've solidified my thoughts yet

I can wait if you would prefer more time to think about the problem, I
can work on other things in the meantime and we still have several
months before the code freeze. I mainly wanted to share my findings
with this experiment, and that was also a fun side project to try.

> 2) do you agree with the above?

Yes. I'm fine with not verifying everything perfectly (or as close as
perfectly as we can). I like my currently submitted version better
than the child process verification version, but I wanted to see if it
is doable or not, and to see what challenges there are.

> 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.

We could make them reserved names? Or maybe even accessible as GUC
variables, even if we leave the current parsing/validation logic as
is. Making them proper GUC variables seemed like a clear follow up
patch to me, even if not for pg19.

> 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.

I probably should read that thread in more detail, but I assume that
your worry is about pg_hosts being a hardcoded configuration instead
of using a similarly customizable GUC context? Shouldn't that be
fixable in the future similarly?

> 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?

I'm not sure about reusing existing GUC infrastructure, but  I could
make it look similar from the users perspective for example by adding
a function DefineCustomValidatorStringVariable that has a similar
interface to DefineCustomStringVariable, and in the future, this
function could simply forward to DefineCustomStringVariable.

That would limit the variable to be only definable in pg_hba, not
postgresql.conf, but otherwise should work similarly for
validators/users.

I think this would be a larger patch than the real PGC_GUC, but it
would be limited to the pg_hba parser.

> 1) how close to the sun do you feel like flying today?

Now that I have tried the PGC_HBA approach, I like how that works and
integrates with everything, this is a much better solution than my
original ideas.

On the other hand, it would be great to get something working in PG19.
By that time more libraries/tools should actually start to support
oidc, and we will see more use of the feature, and the way we
configure these parameters is important for the validators.