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.