Trying to work in the new role features into the information schema, I noticed that there might be a few incompatibilities between the implementation and what the SQL standard would like to see.
The way I understand this is that, according to the SQL standard, there should be a current user and optionally a current role. A current role can be set by running SET ROLE, and that is only permissible if that role has been granted to the current user. (It seems that this must have been a direct grant, but that is less important.) The set of applicable privileges (used for permission checking) is now the privileges held by the current user, the current role, and all roles that have been granted to the current role. It seems that the "inherit" functionality was invented to simulate something like this but it doesn't quite do it. What we'd really need is a system where roles granted to the current user are not automatically activated but roles granted to the current role are. The inherit functionality is then only to simulate traditional groups that activate all their privileges automatically depending on who is the current user. The other problem is that using SET ROLE activates the privileges of a role but loses the privileges of the current user. In practice this may mean that it reduces your privileges while you might want to use it to augment your privileges. What both of these observations come down to is that in my estimation current user and current role should be separated. It's quite possible that I'm reading this wrong in a hurry or can't quite simulate it right, so please enlighten me. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
