On 03/20/2013 06:40 PM, Adrian Klaver wrote: > On 03/20/2013 03:26 PM, Michael Orlitzky wrote: >> On 03/20/2013 05:18 PM, Rob Sargent wrote: > >> >> At the moment, everyone's just experimenting. Even with the proper >> tooling, my blog app shouldn't have to handle the database permissions >> table-by-table. I should be able to set up sensible defaults. >> > CREATE ROLE adrian LOGIN; > CREATE ROLE ranger LOGIN; > CREATE ROLE dev_user ROLE; > GRANT dev_user TO adrian; > GRANT dev_user TO ranger; > > ALTER ROLE adrian IN DATABASE test set role=dev_user; > > aklaver@panda:~> psql -d test -U adrian > ... Thanks, this is extremely close, but doesn't quite nail it: at the end, what happens if you create a table as ranger? By default, adrian doesn't have access to it. You could of course do, ALTER ROLE ranger IN DATABASE test set role=dev_user; Now everything in the database will be owned by dev_user. But what happens if we have 100 databases (this is realistic for us), and add a new developer a year down the road? I have to not only add him to dev_user, but look through each database, figure out which ones we've used this trick on, and do, ALTER ROLE the_new_guy IN DATABASE foo set role=dev_user; And I can already achieve this result with a pile of scripts. It just feels half-assed. When I add someone to a group, they should inherit the permissions of the group. More convenient, way safer. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
