> On Oct 7, 2021, at 12:31 PM, Mark Dilger <mark.dilger@enterprisedb.com> wrote:
>
> Let me see if I can find that again.
12.6 <drop role statement>
<drop role statement> ::=
DROP ROLE <role name>
Syntax Rules
1) Let R be the role identified by the specified <role name>.
General Rules
1) Let A be any <authorization identifier> identified by a role authorization descriptor as having been granted
to R.
2) The following <revoke role statement> is effectively executed without further Access Rule checking:
REVOKE R FROM A
3) The descriptor of R is destroyed.
So DROP ROLE bob is expected to execute the revoke command. Let's see what that says....
<revoke role statement> ::=
REVOKE [ ADMIN OPTION FOR ] <role revoked> [ { <comma> <role revoked> }... ]
FROM <grantee> [ { <comma> <grantee> }... ]
[ GRANTED BY <grantor> ]
<drop behavior>
31) If RESTRICT is specified, and there exists an abandoned privilege descriptor, abandoned view,
abandoned table constraint, abandoned assertion, abandoned domain constraint, lost domain, lost column,
lost schema, or a descriptor that includes an impacted data type descriptor, impacted collation, impacted
character set, abandoned user-defined type, or abandoned routine descriptor, then an exception condition
is raised: dependent privilege descriptors still exist.
33) Case:
a) If the <revoke statement> is a <revoke privilege statement>, then
... SNIP ...
b) If the <revoke statement> is a <revoke role statement>, then:
i) If CASCADE is specified, then all abandoned role authorization descriptors are destroyed.
ii) All abandoned privilege descriptors are destroyed.
34) For every abandoned view descriptor V, let S1.VN be the <table name> of V. The following <drop view
statement> is effectively executed without further Access Rule checking:
DROP VIEW S1.VN CASCADE
35) For every abandoned table descriptor T, let S1.TN be the <table name> of T. The following <drop table
statement> is effectively executed without further Access Rule checking:
DROP TABLE S1.TN CASCADE
The way I read that, DROP ROLE implies REVOKE ROLE, and I'm inferring that DROP ROLE CASCADE would therefore imply
REVOKEROLE CASCADE. Then interpreting 31's description of how REVOKE ROLE RESTRICT works under the principle Expressio
UniusEst Exclusio Alterius I conclude that REVOKE ROLE CASCADE must not raise an exception. That leads me to the
conclusionthat DROP ROLE CASCADE must not raise an exception.
Sorry for misremembering this as something you said.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
