Re: Mystery with REVOKE PRIVILEGE - Mailing list pgsql-hackers

From Konstantin Knizhnik
Subject Re: Mystery with REVOKE PRIVILEGE
Date
Msg-id c8e166a6-173b-4637-8e94-4b447b49adab@garret.ru
Whole thread Raw
In response to Re: Mystery with REVOKE PRIVILEGE  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Mystery with REVOKE PRIVILEGE
List pgsql-hackers
On 21/01/2026 1:07 AM, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
>> On Tue, Jan 20, 2026 at 04:32:31PM -0500, Tom Lane wrote:
>>> I don't think "let's make select_best_grantor even more magic"
>>> is the right approach.  IMO, if there is a GRANTED BY clause,
>>> we should use exactly that grantor and not apply select_best_grantor
>>> at all.  This is, for example, certainly the behavior needed for
>>> pg_dump.
>> I started on something like that here:
>>     https://postgr.es/m/aRYLkTpazxKhnS_w%40nathan
> Ah, I wonder if that discussion was lurking in my hindbrain.
> I just posted a different take on how to do it in that thread,
> but the behavioral change should be the same.
>
>             regards, tom lane


Thank you.
Fixing explicit grantor case is definitely the most critical thing.
And I completely agree with your patch.
But I wonder if we do refactoring of this revoke privileges stuff, 
should we also provide correct (expected) behaviour in case of missing 
grantor specification. i.e.

      revoke all privileges on table <T> from <role>;

If privileges to access this table were granted to this role by multiple 
grantors, then it is natural to expect that the statement above will 
remove all such grants and so as a result <role> can not access this 
table any more, rather than try to find best grantor and finally still 
leave privileges for this role, isn't it?





pgsql-hackers by date:

Previous
From: Tatsuro Yamada
Date:
Subject: Re: [PATCH] psql: add \dcs to list all constraints
Next
From: Zsolt Parragi
Date:
Subject: Re: CREATE TABLE LIKE INCLUDING TRIGGERS