Re: Mystery with REVOKE PRIVILEGE

Поиск
Список
Период
Сортировка
От Konstantin Knizhnik
Тема Re: Mystery with REVOKE PRIVILEGE
Дата
Msg-id c8e166a6-173b-4637-8e94-4b447b49adab@garret.ru
обсуждение исходный текст
Ответ на Re: Mystery with REVOKE PRIVILEGE  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Mystery with REVOKE PRIVILEGE
Список 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 по дате отправления: