Re: replacing role-level NOINHERIT with a grant-level option
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: tushar <tushar.ahuja@enterprisedb.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
Joe Conway <mail@joeconway.com>, Tom Lane <tgl@sss.pgh.pa.us>, "Bossart, Nathan" <bossartn@amazon.com>, Stephen Frost <sfrost@snowman.net>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2022-07-28T14:33:08Z
Lists: pgsql-hackers
On Thu, Jul 28, 2022 at 10:16 AM tushar <tushar.ahuja@enterprisedb.com> wrote: > On 7/19/22 12:56 AM, Robert Haas wrote: > > Another good catch. Here is v5 with a fix for that problem. > Here is one scenario in which I have NOT granted (inherit false) > explicitly but still revoke > command is changing the current state > > postgres=# create group foo; > CREATE ROLE > postgres=# create user bar in group foo; > CREATE ROLE > postgres=# revoke inherit option for foo from bar; > REVOKE ROLE > > [edb@centos7tushar bin]$ ./pg_dumpall > /tmp/a11 > > [edb@centos7tushar bin]$ cat /tmp/a11 |grep 'inherit false' -i > GRANT foo TO bar WITH INHERIT FALSE GRANTED BY edb; > > I think this revoke command should be ignored and inherit option should > remain 'TRUE' > as it was before? No, it seems to me that's behaving as intended. REVOKE BLAH OPTION ... is intended to be a way of switching an option off. -- Robert Haas EDB: http://www.enterprisedb.com
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix a bug in roles_is_member_of.
- 0101f770a05b 16.0 landed
-
docs: Fix up some out-of-date references to INHERIT/NOINHERIT.
- 620ac285483f 16.0 landed
-
Allow grant-level control of role inheritance behavior.
- e3ce2de09d81 16.0 landed
-
Make role grant system more consistent with other privileges.
- ce6b672e4455 16.0 cited
-
Document basebackup_to_shell.required_role.
- 26a0c025e233 15.0 landed