Re: allowing for control over SET ROLE

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.