From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Erik Wienhold <ewie(at)ewie(dot)name> |
Cc: | Stuart McGraw <smcgraw(at)mtneva(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Restoring default privileges on objects |
Date: | 2023-08-29 14:14:45 |
Message-ID: | 1006397.1693318485@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Erik Wienhold <ewie(at)ewie(dot)name> writes:
> On 29/08/2023 03:23 CEST Stuart McGraw <smcgraw(at)mtneva(dot)com> wrote:
>> If I've done a GRANT or REVOKE on some of the tables, how do I restore
>> the default privileges so that the “Access privileges” appears empty
>> again? I re-granted what I think are the default privileges but the
>> "Access privileges" column for that table contains "user1=arwdDxt/user1"
>> rather than being blank. This is Postgresql-14.
> Yes, "user1=arwdDxt/user1" matches the default privileges if user1 is the table
> owner.
Right. There is no (supported) way to cause the ACL entry to go back
to null. It starts life that way as an ancient hack to save a step
during object creation. But the moment you do anything to the object's
privileges, the NULL is replaced by an explicit representation of the
default privileges, which is then modified per whatever command you
are giving. After that the privileges will always be explicit.
There's been occasional discussion of changing this behavior, but
it'd take work and it'd likely add about as much surprise as it
removes. People have been used to this quirk for a long time.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stuart McGraw | 2023-08-29 16:43:45 | Re: Restoring default privileges on objects |
Previous Message | Erik Wienhold | 2023-08-29 11:22:31 | Re: Restoring default privileges on objects |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-08-29 14:18:36 | Re: Debian 12 gcc warning |
Previous Message | Tom Lane | 2023-08-29 14:01:47 | Re: Wrong usage of pqMsg_Close message code? |