Re: Custom oauth validator options

On Tue, Jan 20, 2026 at 12:31 PM Zsolt Parragi
<zsolt.parragi@percona.com> wrote:
> > 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?

I'm wondering if we should maybe do the opposite, and namespace the
GUCs instead? The vast majority of settings in an HBA are not going to
be GUCs, they're going to be method-specific parameters. So maybe it's
okay to have to do more typing to do the uncommon thing, and reference
them like `guc.log_connections` or something.

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

Hmm... we may want to discuss my (e) option derailment more seriously,
if we're planning to go in that direction (and if other people like
that direction).

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

"Fixable" in what sense? pg_hosts.conf is currently similar to
pg_ident.conf in that it has no place for key=value pairs, and if you
add them after as an optional "column" for compatibility, you still
have to write something for all of those columns that you were trying
to replace with the GUC settings.

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

Might work, yeah.

--Jacob