On 03/20/2013 02:24 PM, Michael Orlitzky wrote:
On 03/20/2013 04:12 PM, Alvaro Herrera wrote:
Michael Orlitzky wrote:
I'm running into this exact situation:

http://www.postgresql.org/message-id/CAG1_KcBFM0e2buUG=o7ojq_ktadrzdgd45ju7gke3duz0sz...@mail.gmail.com

We really need to be able to have a group of developers who can create
things and modify each others' stuff[1]. Is it still more or less
impossible?

The workaround that comes to mind is a script to enumerate all
"developers" and then set the defaults one at a time. This breaks
however when we add a new developer -- he can't access any of the
existing stuff.

I don't understand.  Why doesn't alice do a "set role dev_user" before
creating the table?  Then, the table owner is dev_user, not alice, and
default privileges for dev_user apply.  In fact you needn't run ALTER
DEFAULT PRIVILEGES at all, because dev_user will be owner of the
objects, and both alice and bob have that role.


It comes down to a separation of concerns. These developers shouldn't
(and really, don't) know/care what the privileges should be. They don't
know that they're even in a group. Why should they?

As with filesystem permissions, the admin should be able to set this all
up (correctly) and forget about it.



What's your process? First I've heard of a group of dev's ignorant of permission _and_ trusted to change things in a db which affect others.

If they are in a group, can that not define the role and go from there with std permission layouts?

Are these mostly DDL changes? Might want to look at migrations tools (MyBatis, flyway and others)



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Reply via email to