Re: The presence of a NULL "defaclacl" value in pg_default_acl prevents the dropping of a role.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: The presence of a NULL "defaclacl" value in pg_default_acl prevents the dropping of a role.
Дата
Msg-id 4099506.1704214572@sss.pgh.pa.us
обсуждение исходный текст
Ответ на The presence of a NULL "defaclacl" value in pg_default_acl prevents the dropping of a role.  ("杨伯宇(长堂)" <yangboyu.yby@alibaba-inc.com>)
Список pgsql-hackers
"=?UTF-8?B?5p2o5Lyv5a6HKOmVv+Wggik=?=" <yangboyu.yby@alibaba-inc.com> writes:
> postgres=# create user adminuser;
> CREATE ROLE
> postgres=# create user normaluser;
> CREATE ROLE
> postgres=# alter default privileges for role adminuser grant all on tables to normaluser;
> ALTER DEFAULT PRIVILEGES
> postgres=# alter default privileges for role adminuser revoke all ON tables from adminuser;
> ALTER DEFAULT PRIVILEGES
> postgres=# alter default privileges for role adminuser revoke all ON tables from normaluser;
> ALTER DEFAULT PRIVILEGES
> postgres=# select * from pg_default_acl where pg_get_userbyid(defaclrole) = 'adminuser';
>   oid  | defaclrole | defaclnamespace | defaclobjtype | defaclacl
> -------+------------+-----------------+---------------+-----------
>  16396 |      16394 |               0 | r             | {}
> (1 row)
> postgres=# drop user adminuser ;
> ERROR:  role "adminuser" cannot be dropped because some objects depend on it
> DETAIL:  owner of default privileges on new relations belonging to role adminuser

This looks perfectly normal to me: the privileges for 'adminuser'
itself are not at the default state.  If you then do

regression=# alter default privileges for role adminuser grant all on tables to adminuser ;
ALTER DEFAULT PRIVILEGES

then things are back to normal, and the pg_default_acl entry goes away:

regression=# select * from pg_default_acl;
 oid | defaclrole | defaclnamespace | defaclobjtype | defaclacl
-----+------------+-----------------+---------------+-----------
(0 rows)

and you can drop the user:

regression=# drop user adminuser ;
DROP ROLE

You could argue that there's no need to be picky about an entry that
only controls privileges for the user-to-be-dropped, but it is working
as designed and documented.

I fear your proposed patch is likely to break more things than it fixes.
In particular it looks like it would forget the existence of the
user's self-revocation altogether, even before the drop of the user.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: introduce dynamic shared memory registry
Следующее
От: Nathan Bossart
Дата:
Сообщение: verify predefined LWLocks have entries in wait_event_names.txt