On Wed, Dec 17, 2025 at 1:28 AM Zsolt Parragi wrote:
> Instead we decided to let everyone configure which claim they want to
> use for user mapping. But because of that, this is a GUC, and they can
> only configure it once pre server.
We're getting closer; I agree that this needs to be more flexi
On Tue, Dec 16, 2025 at 10:30 PM VASUKI M wrote:
> Overall, +1 that this limitation is real and worth discussing.I’ll plan to
> send a patch shortly exploring option (b).
Thanks!
> Reg very long HBA lines: totally agree this is a real readability issue,but
> allowing per-line includes or exter
> Overall, +1 that this limitation is real and worth discussing.I’ll plan to
> send a patch shortly exploring option (b).
Personally I would go with either (a) or (c), and I was planning to
clean up / improve / share my (c) patch as a second attempt for this
thread, if it didn't receive any repli
> What kinds of parameters? Having a motivating use case would be
> helpful; HBA isn't always as flexible as people assume and I want to
> make sure that we can end with a usable feature.
One issue we have is that some providers don't allow users to select
what goes into the subject claim, but do
Hi All,
The core issue,as you said,is that OAuth validators can add custom
validation logic,but they can't define their own authentication-related
parameters in pg_hba.conf,where they naturally belong.Because of
that,validator-specific config ends up pushed into postgresql.conf via
GUCs,which feel
Sorry for missing this thread!
On Tue, Dec 2, 2025 at 5:06 AM Zsolt Parragi wrote:
> 1. Configuration for OAuth validation ends up split across two
> locations: issuer/scope and a few other parameters are defined in
> pg_hba.conf, while custom parameters must be set in postgresql.conf.
Yeah. (Th
