On Wed, Dec 17, 2025 at 1:28 AM Zsolt Parragi <[email protected]> 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 flexible than it is, and I'm on board with a change, but I'm still missing the "killer app". What's the case where a user has multiple HBA lines that all want to use unrelated claims for authentication to one Postgres cluster? Is this multi-tenancy, or...? > I tried to propose simple things that are relatively easy to > implement, and wouldn't change too much at once, so there's a > realistic change for this making into PG19. I'm not against having a > bigger goal, and continuing making it even better after that. Absolutely -- that's a tried and true strategy. No objections to that. But I also didn't want to stay silent on my longer-term goals here. That way (hopefully), no one's surprised to find I'm lukewarm on patches that are extremely OAuth-specific, or that don't give us a way to improve/evolve later. The additional flexibility of OAuth should ideally be mirrored in other auth methods when possible. > > A hypothetical PGC_HBA context would seem to fit nicely between > > PGC_SIGHUP and PGC_SU_BACKEND. > > How would you configure that since the hba lines don't have IDs? > Should we add a "guc_name" parameter to HBA for this or something like > that? I like this idea, it would be fun to implement and see how it > works, I'm just wondering how users could use it. I hadn't thought it through very far; my initial impression was that we'd need some sort of additional syntax. But I keep coming back to httpd-style configs and then I choose something else from my TODO list to focus on. :) See also the old conversation regarding LDAP hba/ident [1]. On Wed, Dec 17, 2025 at 1:36 AM Zsolt Parragi <[email protected]> wrote: > 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 replies. I can still do that, so that > we have multiple test implementations. The more the merrier! Thanks, --Jacob [1] https://postgr.es/m/CAOuzzgpFpuroNRabEvB9kST_TSyS2jFicBNoXvW7G2pZFixyBw%40mail.gmail.com
