Re: Custom oauth validator options

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
Cc: VASUKI M <vasukianand0119(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, david(dot)g(dot)johnston(at)gmail(dot)com, Robert Haas <robertmhaas(at)gmail(dot)com>, myon(at)debian(dot)org
Subject: Re: Custom oauth validator options
Date: 2026-01-05 18:53:06
Message-ID: CAOYmi+=-OdzHMzqg9i8TwYvgKwE-vroj0d-9SqnRnwbz02SgTg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 18, 2025 at 12:29 PM Zsolt Parragi
<zsolt(dot)parragi(at)percona(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2026-01-05 18:58:51 Re: Adding NetBSD and OpenBSD to Postgres CI
Previous Message Masahiko Sawada 2026-01-05 18:51:11 Re: POC: Parallel processing of indexes in autovacuum