On 04/07/10 21:43, Davor J. wrote: > PS using inheritance in this scenario is problematic. Yep. Just one issue is that roles are cluster-wide, whereas tables are visible only inside a single database. I generally use the role mechanism as-is, granting users access to roles that control particular privileges. Especially now that Pg has column privileges I rarely even need to use triggers to check for role membership - the standard permissions model is increasingly sufficient. If it's not for you, you could always maintain a table of additional privilege information that new roles with default privileges are added to when a priv check function first "sees" them. With a (say) daily pass to remove entries associated with roles that no longer exist, that should be fine. It's not as nice as using a proper inheritance/extension mechanism, but it leaves you a lot safer from changes caused by PostgreSQL upgrades. -- Craig Ringer -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
