Re: BUG #14007: log_statement doesn't work when applied to a 'group'

On Tue, Mar 8, 2016 at 3:14 PM, <ryan(dot)schannauer(at)vwr(dot)com> wrote:

> The following bug has been logged on the website:
>
> Bug reference: 14007
> Logged by: Ryan Schannauer
> Email address: ryan(dot)schannauer(at)vwr(dot)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='all' for each individual user. Is this
> by design?
>
>
​Yes. You have to read a bit between the lines in the documentation 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
"""
> ​Values set with ALTER DATABASE and ALTER ROLE are applied only when
starting a fresh database session.

​"""
http://www.postgresql.org/docs/9.5/static/config-setting.html#CONFIG-SETTING-SQL-COMMAND-INTERACTION

and
"""​
​> ​
Role-specific variable settings take effect only at login; SET ROLE and SET
SESSION AUTHORIZATION do not process role-specific variable settings.
​"""
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 ​and 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.