On 03/11/2014 09:57 AM, Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> On Tue, Mar 11, 2014 at 2:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Are you claiming there are no users, and if so, on what evidence?
>> I am claiming that I don't think anybody is using that, yes.
>> Based on the fact that I have *never* come across it on any system I've
>> come across since, well, forever. Except once I think, many years ago, when
>> someone had enabled it by mistake and needed my help to remove it...
> A slightly more scientific basis for that would be to ask on
> pgsql-general.
>
>> Or if someone wants to fix it properly of course :)
> Yeah, that's what we've been hoping for for 12 years. I stopped holding
> my breath awhile ago.
>
> Mind you, I wouldn't be unhappy to see it go away; it's a kluge and always
> has been. I'm just expecting lots of push-back if we try. And it's kind
> of hard to resist push-back when you don't have a substitute to offer.
>
>
Or we try to make it work. I don't think the idea is inherently bad, and
I know there are people (like ISPs) who would like to have it work
properly. Maybe in these days when most people are on dedicated VMs this
matters less, but I don't think shared database servers are totally dead
yet.
The docs say:
db_user_namespace causes the client's and server's user name representation to differ. Authentication checks are
alwaysdone with the server's user name so authentication methods must be configured for the server's user name, not
theclient's. Because md5 uses the user name as salt on both the client and server, md5 cannot be used with
db_user_namespace.
Is that the only major issue? Why not have the server strip out the @db
part if this is on? If we made this an initdb-time setting rather than a
GUC then we'd remove the problems caused by turning this on and off. I'm
not sure what other problems that might cause, but it doesn't seem
totally intractable at first glance.
cheers
andrew