On Sat, Mar 17, 2007 at 01:47:11AM +0300, Dmitry Koterov wrote: > When we start using of any replication system (e.g. Slony) we need to create > a "read-only" role for access the database. This role must be able to read > anything, but should NOT be able to INSERT, UPDATE or DELETE for all > database objects. It may be possible to set the session to read-only "set session characteristics as transaction readonly" and make that the default (along the lines of "alter database set ...") for the readonly role. There may be a way to disallow that role to change that characteristic. > Overall, we need 3 roles: > > 1. Administrator: can do anything with a database (by default this user is > already exists - "postgres"). > 2. Read-only: can only read. Runs on all slave nodes. > 3. Read-write: can write, but cannot change the database schema. Runs on > master node only. > > Is any way to easily create and maintain these standard roles? > > Now I have written a stored procedure which iterates over the pg_catalog and > runs a lot of REVOKE & GRANT commands, but it seems to be not an universal > solution, because: > > 1. I have to re-run this procedure after I change the database schema. (Very > bad item! Can we avoid it?) > 2. It looks like a "broot-force" method, and nothing said about it in the > Slony documentation (strange). > 3. In MySQL (e.g.) there is a one-command way to create these three roles. > > Again, these 3 roles seems to be a de-facto standard for replication > systems, but I found nothing about this question in the Google. -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
