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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers