Odkryłem, że lepszym podejściem (i wydaje mi się, że zostało to zaczerpnięte z niektórych zapytań wbudowanych w psql lub może widoków information_schema) jest użycie has_*_privilege funkcji i po prostu zastosuj je do zbioru wszystkich możliwych kombinacji użytkownika i obiektu. Uwzględni to również posiadanie dostępu do obiektu poprzez pewną rolę grupową.
Na przykład pokaże to, którzy użytkownicy mają dostęp do tabel i widoków niekatalogowych:
select usename, nspname || '.' || relname as relation,
case relkind when 'r' then 'TABLE' when 'v' then 'VIEW' end as relation_type,
priv
from pg_class join pg_namespace on pg_namespace.oid = pg_class.relnamespace,
pg_user,
(values('SELECT', 1),('INSERT', 2),('UPDATE', 3),('DELETE', 4)) privs(priv, privorder)
where relkind in ('r', 'v')
and has_table_privilege(pg_user.usesysid, pg_class.oid, priv)
and not (nspname ~ '^pg_' or nspname = 'information_schema')
order by 2, 1, 3, privorder;
Możliwe uprawnienia są szczegółowo opisane w opisie has_*_privilege funkcje na http://www .postgresql.org/docs/current/static/functions-info.html#FUNCTIONS-INFO-ACCESS-TABLE
.
„CREATE TEMP” to uprawnienie na poziomie bazy danych:pozwala użytkownikowi na użycie pg_temp_* schemat. Można go przetestować za pomocą has_database_privilege(useroid, datoid, 'TEMP') .
