I'm wondering about making the list of things you can specify in
require_auth less confusing and future proof.
For example, before long someone is going to try putting "ldap" into
require_auth. The fact that the methods in pg_hba.conf are not what
libpq sees is not something that was really exposed to users until now.
"none" vs. "trust" takes advantage of that. But then I think we could
also make "password" clearer, which surely sounds like any kind of
password, encrypted or not, and that's also how pg_hba.conf behaves.
The protocol specification calls that "AuthenticationCleartextPassword";
maybe we could pick a name based on that.
And then, what if we add a new method in the future, and someone puts
that into their connection string. Old clients will just refuse to
parse that. Ok, that effectively gives you the same behavior as
rejecting the server's authentication offer. But what about the negated
version? Also, what if we add new SASL methods. How would we modify
this code to be able to pick and choose and also have backward and
forward compatible behavior?
In general, I like this. We just need to think about the above things a
bit more.