From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Thom Brown <thom(at)linux(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Per-Database Roles |
Date: | 2012-05-22 14:19:41 |
Message-ID: | 20120522141941.GM1267@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Thom Brown (thom(at)linux(dot)com) wrote:
> Conflicts would occur where localrolename matches an existing local
> role name within the same database, or a global role name, but not a
> local role name within another database. The problem with this,
> however, is that creating global roles would need conflict checks
> against local roles in every database, unless a manifest of all local
> roles were registered globally.
Hmm, right, that's a bit of a sticky point. wrt your suggestion- it
works great if we don't allow duplicates, but then people have to accept
their role name is getting changed. That said, perhaps that's not that
big of a deal, since you could rename it afterwards.
The issue with the constraints on other databases might actually be
cause enough to allow duplicates, just to avoid that issue.. We could
mirror the per-database roles into a shared space that isn't externally
visible, but at that point, maybe we should try to get RLS for the
catalogs instead, or just modify the views to only show roles which can
connect to this database. That's not going to make them completely
transparent, but it might be enough for some use cases.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2012-05-22 14:21:48 | Re: Draft release notes complete |
Previous Message | Robert Haas | 2012-05-22 14:19:12 | Re: Per-Database Roles |