On Wed, Aug 26, 2026 at 11:07 AM Florin Irion <[email protected]> wrote: > > * How should multiple URI SAN entries be handled (first match, require > > uniqueness, mapping rules, etc.)? > > The key thing is that the client must tell PostgreSQL which user they want to > connect as. Then PostgreSQL looks through all the mappings it found and > checks if any of the SANs map to that requested user. If exactly one SAN > matches the user, we allow the connection. If none match, we reject. If many > SANs map to different users but the client already said which one they want, > that is fine, we just use the right one.
I interpreted the question about "first match" to mean: what if many SANs in the cert map to the *same* database user? (IMO an implementation of this that ignored pg_ident mapping would be vetoable without a really, _really_ good reason, so I'm not sure that branch of the discussion needs to consume much energy.) > I think this is better than trying to pick the first match automatically, > because that can be confusing. I don't understand what you mean here, in the context of our startup handshake. We don't allow you to omit the database username from the startup packet, so there couldn't be any guesswork around which DB role a client meant to connect under. > The pg_ident.conf rules let you organize this however makes sense for your > setup. Sort of. We're currently pretty bad at allowing you to say "or" in the HBA. So without more design work, I don't think there's going to be a way to dynamically switch the `clientname` setting from CN to DN to URI (to email, to other SAN...); you'd have to choose one and stick to it for a given HBA line. --Jacob
