On 24.07.23 08:42, Pavel Luzanov wrote:
I do see what seems like a different issue: the standard appears to
expect
that indirect role grants should also be shown (via the recursive CTE),
and we are not doing that.
I noticed this, but the view stays unchanged so long time.
I thought it was done
On 24.07.2023 09:42, Pavel Luzanov wrote:
Is IS_GRANTABLE a key column for ROLE_AUTHORIZATION_DESCRIPTORS?
If not, duplicates is not possible. Right?
The answer is: no.
Duplicate pairs (grantee, role_name) is impossible only with defined key
with this two columns.
If there is no such key or k
On 23.07.2023 23:03, Tom Lane wrote:
CREATE RECURSIVE VIEW APPLICABLE_ROLES ( GRANTEE, ROLE_NAME, IS_GRANTABLE ) AS
( ( SELECT GRANTEE, ROLE_NAME, IS_GRANTABLE
FROM DEFINITION_SCHEMA.ROLE_AUTHORIZATION_DESCRIPTORS
WHERE ( GRANTEE IN
( CURRENT_USER, 'PUBLIC'
Pavel Luzanov writes:
> The application_roles view shows duplicates:
> postgres@postgres(17.0)=# SELECT * FROM
> information_schema.applicable_roles WHERE grantee = 'alice';
> grantee | role_name | is_grantable
> -+---+--
> alice | bob | NO
> alice | b
I found that multiple membership grants added in v16 affects the
information_schema.applicable_roles view.
Examples on a master, but they works for v16 too.
Setup multiple membership alice in bob:
postgres@postgres(17.0)=# \drg alice
List of role grants
Role name | Member of |
