Re: db_user_namespace a "temporary measure" - Mailing list pgsql-hackers

From David Johnston
Subject Re: db_user_namespace a "temporary measure"
Date
Msg-id 1394599165991-5795609.post@n5.nabble.com
Whole thread Raw
In response to Re: db_user_namespace a "temporary measure"  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Andrew Dunstan wrote
> On 03/11/2014 11:50 PM, Jaime Casanova wrote:
>> On Tue, Mar 11, 2014 at 10:06 PM, Tom Lane <

> tgl@.pa

> > wrote:
>>> But not sure how to define a unique
>>> index that allows (joe, db1) to coexist with (joe, db2) but not with
>>> (joe, 0).
>>>
>> and why you want that restriction? when you login you need to specify
>> the db, right? if you don't specify the db then is the global 'joe'
>> that want to login
>>
> 
> You can't login without specifying a db. Every session is connected to a
> db.
> 
> cheers
> 
> andrew

Random Thoughts:

So if dave is already a user in db1 only that specific dave can be made a
global user - any other dave would be disallowed.

Would "user - password" be a better PK? Even with the obvious issue that
password part of the key can change.  "user-password to database" is a
properly many-to-many relationship.  Or see next for something simpler.

A simple implementation would simply have the global users copied into each
database as it is constructed.  There would also be a link from each of the
database-specific users and the global master so that a password change
issued against the global user propagates to all the database-specific
versions.

Construction of a new global user would cause an immediate copy-over; which
can fail if the simple name is already in use in any of the existing
databases.  "Promoting" becomes a problem that would ideally have a solution
- but then you are back to needing to distinguish between "dave-db1" and
"dave-db2"...

Be nice if all users could be "global" and there would be some way to give
them permissions on databases.

Or go the opposite extreme and all users are local and the concept of
"global" would have to be added by those desiring it.  Basically move
user-management at the cluster level to a cluster support application and
leave databases free-standing.

David J.




--
View this message in context:
http://postgresql.1045698.n5.nabble.com/db-user-namespace-a-temporary-measure-tp5795305p5795609.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.



pgsql-hackers by date:

Previous
From: Haribabu Kommi
Date:
Subject: Re: contrib/cache_scan (Re: What's needed for cache-only table scan?)
Next
From: Kouhei Kaigai
Date:
Subject: Re: Custom Scan APIs (Re: Custom Plan node)