> Hmm... we may want to discuss my (e) option derailment more seriously, > if we're planning to go in that direction (and if other people like > that direction).
I know you wrote that you are only half serious about it, and I definitely do not want to go in the "lets completely refactor pg_hba in this patch" direction, but keeping that idea in mind seems like a good idea to me. The choosing authentication method part would already be useful with OAuth, and now Joel also started a thread about fido2, which also brings the question of MFA. Pluggable generic authentication would also require generic GUC variables at this level. Scoping validators to a specific prefix fixes the collision issue, but it also goes in a different direction. Because of this I like the other alternative idea (DefineCustomValidatorStringVariable) better, if we want to go with a smaller change for this, but I still have to implement that and see how it behaves in practice. > "Fixable" in what sense? pg_hosts.conf is currently similar to > pg_ident.conf in that it has no place for key=value pairs, and if you > add them after as an optional "column" for compatibility, you still > have to write something for all of those columns that you were trying > to replace with the GUC settings. pg_hba has the same issue, even if it has custom key=value data already. What I meant is similarly how we could turn currently hard coded pg_hba settings into GUC variables, the same is doable with pg_hosts, either at a separate level or integrating it into the HBA context. And later either both should get a new line style and deprecate the old one, or maybe these settings should be configured completely differently.
