Sorry for the multiple consecutive emails. I just came across this
comment that explains the current behavior in restrict_and_check_grant
/*
* Restrict the operation to what we can actually grant or revoke, and
* issue a warning if appropriate. (For REVOKE this isn't quite what the
* spec says to
I've been thinking about this some more and reading the SQL99 spec. In
the original thread that added these warnings [0], which was linked
earlier in this thread by Nathan, the following assertion was made:
> After that, you get to the General Rules, which pretty clearly say that
> trying to grant
On Thu, May 18, 2023 at 7:17 PM Joseph Koshakow wrote:
>
>I looked into this function and that is correct. We fail to find a
>match for the revoked privilege here:
>
>/*
>* Search the ACL for an existing entry for this grantee and grantor. If
>* one exists, just modify the entr
On Wed, May 17, 2023 at 11:48 PM Nathan Bossart
wrote:
>
>The thread for the aforementioned change [0] mentions the standard
quite a
>bit, which might explain the current behavior.
I went through that thread and the quoted parts of the SQL standard. It
seems clear that if a user tries to
On Mon, May 15, 2023 at 11:23:22PM -0400, Joseph Koshakow wrote:
> Reading through the docs [0], I'm not actually sure if the REVOKE
> in the second example should succeed or not. At first it says:
>
>> A user can only revoke privileges that were granted directly by that
>> user. If, for example,
Hi Hackers,
I noticed some confusing behavior with REVOKE recently. Normally if
REVOKE fails to revoke anything a warning is printed. For example, see
the following scenario:
```
test=# SELECT current_role;
current_role
--
joe
(1 row)
test=# CREATE ROLE r1;
CREATE ROLE
test=# CREAT
