> "Connections using SCRAM authentication should time out in X seconds > instead of the default." Or "this group of users should use the > following list of GUCs." The sample I used in [1] a long time ago was > > Everyone has to use LDAP auth > With this server > And these TLS settings > > Except admins > who additionally need client certificates > with this CA root > > And Jacob > who isn't allowed in anymore
The first 2 options would fit easily into my mockups, as if I parse that correctly, that is tied to our HBA GUC discussion I linked in earlier messages. About the second part of it, and the issue with arrays, I agree that I could imagine a better way of configuring things than mapping current pg_hba 1:1 to a different file format. But I also didn't want to propose changing too many things at once. If we already have HBA information stored in generic structured file format such as JSON/TOML, then refactoring/extending it seems easier to me than doing everything in one step. If we do everything in one step, it will be a really ambitious big patch, touching many different parts of postgres. Another option would be first refactoring the authentication logic internally, leaving the user interface (configuration) limited to what's currently available with pg_hba, so that the new configuration file only has to make the new features available instead of implementing from scratch. But that seems like doing things backwards to me.
