Re: db_user_namespace, md5 and changing passwords

Bruce Momjian wrote:
> Bruce Momjian wrote:
>> Alvaro Herrera wrote:
>>> Tom Lane escribi?:
>>>> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>>>>> I don't know of a way to make MD5 and db_user_namespace work cleanly so
>>>>> we are considering removing db_user_namespace in 8.4.
>>>> We are? It's no more or less ugly than the day it was put in (the
>>>> MD5 encryption option was already there).
>>>>
>>>> If we had some improved replacement to offer, I'd be all for getting
>>>> rid of db_user_namespace; but without that I think we're just taking
>>>> away a feature that some people are using. At least, the argument
>>>> was made back in 2002 that people would use this if they had it;
>>>> do we have evidence to the contrary now?
>>> I also disagree with removing it. I know some people (few and far
>>> apart) are using it.
>> Well, I posted about this in August with no one replying:
>>
>> http://archives.postgresql.org/pgsql-admin/2008-08/msg00068.php
>>
>> Basically, there is a mismatch between what libpq and the backend think
>> is the username, and that affects how MD5 uses the salt on the two sides
>> of the connection. The minimal solution would be to document this and
>> print a proper error message.
>
> I have developed the attached patch, which documents the inability to
> use MD5 with db_user_namespace, and throws an error when it is used:
>
> psql: FATAL: MD5 authentication is not supported when "db_user_namespace" is enabled

IMHO it would be much nicer to detect this when we load pg_hba.conf.
It's easy to do these days :-P

I don't think we need to worry about the "changed postgresql.conf after
we changed pg_hba.conf" that much, because we'll always reload
pg_hba.conf after the main config file.

I'd still leave the runtime check in as well to handle the "loaded one
but not the other" case, but let's try prevent the user from loading the
broken config file in the first place..

//Magnus