> 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.
