On 31.08.22 14:56, Robert Haas wrote:
In some circumstances, it may be desirable to control this behavior. For example, if we GRANT pg_read_all_settings TO seer, we do want the seer to be able to read all the settings, else we would not have granted the role. But we might not want the seer to be able to do this:You are now connected to database "rhaas" as user "seer". rhaas=> set role pg_read_all_settings; SET rhaas=> create table artifact (a int); CREATE TABLE rhaas=> \d List of relations Schema | Name | Type | Owner --------+----------+-------+---------------------- public | artifact | table | pg_read_all_settings (1 row)
I think this is because we have (erroneously) make SET ROLE to be the same as SET SESSION AUTHORIZATION. If those two were separate (i.e., there is a current user and a separate current role, as in the SQL standard), then this would be more straightforward.
I don't know if it's possible to untangle that at this point.
