"Optional ident" authentication

Is there a reason other than existing code why HBA should not allow
"ident" to be combined with other authentication methods?

Right now there's no fall-back mechanism for when an ident map doesn't
cover a particular login attempt. The code isn't really structured to
allow one, and I've assumed that that is the only real reason it isn't
there.

My personal itch is that I'd like to have an "ident sameuser"
authentication that falls back on, say, PAM authentication when system
user A wants to log into postgres under a different username B.

To scratch that itch I've made a patch that adds a new authentication
method called optident. It behaves like ident except that it continues
walking down the HBA configuration on failure. AFAICS the patch should
allow you, for example, to grant a web application or daemon passwordless
login to its database while other users still need a password. That seems
a bit safer than storing plaintext passwords in config files (and more
often than not, forget to make them non-readable to untrusted users) like
PHP/MySQL applications tend to do.

It's a fairly radical patch in that it changes struct Port (from hba.h).
The auth_method is replaced with a function pointer, and the UserAuth enum
is replaced with a function-pointer typedef. I think I may also add a new
enum for the corresponding password encryption algorithms, which crypt.c
currently special-cases based on authentication method. That wasn't very
pretty in the first place, I think.

Some dead bits of code and text disappear ("trust authentication failed",
"unknown authentication method failed") and no new translatable strings
are added. Another side effect is that the message for "no matching hba
line" is given only when it applies, rather than for every connection that
hits the "reject" method.

Most of the work went into making fallbacks possible in the first place.
One alternative was to allow multiple arguments to authentication methods
in pg_hba.conf, but that would have been just as radical a change. As it
is, the changes are nicely contained--apart from changing the type of that
one field in struct Port.

Before I go any further with this, am I barking up the wrong tree? Am I
missing something? Or is it worth doing?

Jeroen