Mark Dilger <[email protected]> writes:
> I don't see anything wrong with adding roles in pg_authid.h with a #define'd
> Oid. That's actually pretty helpful for anyone writing code against the
> database,
> as they don't have to look up the Oid of the role.
> But why not then grant privileges to that role in information_schema.sql?
To the extent that the desired privileges can be represented at the SQL
level, I agree that that's a better solution than hard-wiring checks in C
code. The problem comes in with cases where that's not fine-grained
enough. Consider a policy like "anybody can select from pg_stat_activity,
but unless you have privilege X, the query column should read as nulls
except for sessions belonging to you". That behavior can't realistically
be represented as a separate SQL privilege. Right now we have "privilege
X" for this purpose hard-coded as "is superuser", but it would be much
better if it were associated with a grantable role.
regards, tom lane
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
