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
-
oauth: Allow validators to register custom HBA options
- b977bd308a09 19 (unreleased) landed
-
Make LOAD of an already-loaded library into a no-op, instead of attempting
- 602a9ef5a7c6 9.0.0 cited