On Tue, Mar 8, 2016 at 3:14 PM, <ryan.schannauer@vwr.com> wrote:
> The following bug has been logged on the website:
>
> Bug reference: 14007
> Logged by: Ryan Schannauer
> Email address: ryan.schannauer@vwr.com
> PostgreSQL version: 9.4.1
> Operating system: linux
> Description:
>
> I have defined a group. I then assign permissions to that group. I then
> assign that group to individual users. I want to be able to log 'all'
> statements for everyone who has been assigned that group. This does not
> work. I need to set log_statement=3D'all' for each individual user. Is =
this
> by design?
>
>
=E2=80=8BYes. You have to read a bit between the lines in the documentatio=
n though.
Inheritance pertains only the privileges controlled by GRANT/REVOKE.
"""
> These clauses determine whether a role "inherits" the privileges of roles
it is a member of
"""
http://www.postgresql.org/docs/9.5/static/sql-createrole.html
and
"""
> =E2=80=8BValues set with ALTER DATABASE and ALTER ROLE are applied only w=
hen
starting a fresh database session.
=E2=80=8B"""
http://www.postgresql.org/docs/9.5/static/config-setting.html#CONFIG-SETTIN=
G-SQL-COMMAND-INTERACTION
and
"""=E2=80=8B
=E2=80=8B> =E2=80=8B
Role-specific variable settings take effect only at login; SET ROLE and SET
SESSION AUTHORIZATION do not process role-specific variable settings.
=E2=80=8B"""
http://www.postgresql.org/docs/9.5/static/sql-alterrole.html
The take-away is that there is no inheritance involved with ALTER ROLE ...
SET =E2=80=8Band thus it only makes sense to issue it against login roles.
The main issue with making SET inheritable is dealing with multiple
inheritance. The cost of doing hierarchy traversal seems immaterial and
supposedly could be performed during write instead of read (i.e., a trigger
when the relevant catalog is updated).
David J.
