pgman@candle.pha.pa.us (Bruce Momjian) wrote:
> Tom Lane wrote:
>> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> > I don't know where else to go with the patch at this point. I
>> > think increasing the number of 'global' users is polluting the
>> > namespace too much,
>>
>> Why? If the installation needs N global users, then it needs N
>> global users; who are you to make that value judgment for them?
>>
>> In practice I think an installation that's using this feature is
>> going to have a pretty small number of global users, and so the issue
>> of collisions with local usernames isn't really as big as it's been
>> painted in this thread. We could ignore that issue (except for
>> documenting it) and have a perfectly serviceable feature.
>
> The original idea was that Marc wanted people who could create their
> own users for their own databases. If we make the creation of global
> users too easy, all of a sudden people don't have control over their
> db usernames because they have to avoid all the global user names
> already defined. By adding multiple global users, it is diluting the
> usefulness of the feature.
>
Maybe I am missing something here but shouldnt db access really be part
of the privileges system? If all we are talking about is a quick hack
until this can be implemented correctly, what is the concern with having
so much functionality in the hack? Why does it matter what the actual
usernames can or cant be? For example you could just make everyone with
a username NNNNNN@dbname (where N's are int) local accounts and then
leave everything else alone. The only issue I could see with something
like this would be that someone trying to use this hack wont be able to
give their users names like pudgy@dbname, but who cares? I mean if you
are giving access to a bunch of developers, how is it going to affect
them if you tell them to login with 123456@yourdb instead of
jsmith@yourdb? If they cant remember it or something maybe they can
write it down? I dunno...
