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_KtadrzDGd45jU7Gke3dUZ0Sz92g@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)