Re: Custom oauth validator options

Jacob Champion <jacob.champion@enterprisedb.com>

From: Jacob Champion <jacob.champion@enterprisedb.com>
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
Date: 2026-01-05T18:53:06Z
Lists: pgsql-hackers
On Thu, Dec 18, 2025 at 12:29 PM Zsolt Parragi
<zsolt.parragi@percona.com> wrote:
>
> > I think I need to do more staring at the intersection of GUC
> > registration and session_preload_libraries, because my memory of the
> > order of operations was faulty. I won't be able to do that before the
> > holidays, most likely.
>
> Maybe I'm missing something, but why do we need
> session_preload_libraries?

Well, how do you want "global" GUCs registered by the validator to
behave when OAuth isn't used for the connection?

> The question is if non-validator libraries should be able to define
> PGC_HBA variables.

I think we should try for that, yeah. Otherwise I suspect considerable
pushback on the idea of modifying the GucContext enum for something
that can only be used by OAuth.

> * require session_preload_libraries. We proceed with authentication
> even with unresolved HBA variables, but abort the connection if there
> are still unknown parameters after loading session preload.

Of those choices, this _seems_ nicest. It'd be good to get a feel for
how it behaves in practice though.

Thanks,
--Jacob



Commits

  1. oauth: Allow validators to register custom HBA options

  2. Make LOAD of an already-loaded library into a no-op, instead of attempting