Re: [HACKERS] Kerberos brokenness and oops question in 8.1beta2

> The point is I'm having a hard time seeing what the actual
> gain is in not changing it back. If the principal name
> mismatches, we're going to get rejected anyway, so it's not
> really a problem there. Even though the gain in changing it
> back isn't all that big either, why should we introduce
> abackwards-incompatibility if there is no real gain in a
> different part of the code.

Here's a patch that fixes the big problem and reverts the behaviour of
appl_version to be compatible with 8.0. It's easy enough to isolate the
changes that are around the appl_version - one line in
backend/libpq/auth.c call to krb5_recvauth and one in
interfaces/libpq/fe-auth.c call to krb5_sendauth.

The call in backend/libpq/auth.c to krb5_sname_to_principal in 8.1beta2
was completely broken for a scenario where you *didn't* use virtual
hosts, by setting pg_krb5_server to NULL... The call is needed there as
well.

//Magnus