Re: predefined role(s) for VACUUM and ANALYZE - Mailing list pgsql-hackers

From Pavel Luzanov
Subject Re: predefined role(s) for VACUUM and ANALYZE
Date
Msg-id a2382acd-e465-85b2-9d8e-f9ed1a5a66e9@postgrespro.ru
Whole thread Raw
In response to Re: predefined role(s) for VACUUM and ANALYZE  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: predefined role(s) for VACUUM and ANALYZE  (Nathan Bossart <nathandbossart@gmail.com>)
List pgsql-hackers
Hello,

While looking into the new feature, I found the following situation with 
the \dp command displaying privileges on the system tables:

GRANT VACUUM, ANALYZE ON TABLE pg_type TO alice;

SELECT relacl FROM pg_class WHERE oid = 'pg_type'::regclass;
                            relacl
-------------------------------------------------------------
  {=r/postgres,postgres=arwdDxtvz/postgres,alice=vz/postgres}
(1 row)

But the \dp command does not show the granted privileges:

\dp pg_type
                             Access privileges
  Schema | Name | Type | Access privileges | Column privileges | Policies
--------+------+------+-------------------+-------------------+----------
(0 rows)

The comment in src/bin/psql/describe.c explains the situation:

     /*
      * Unless a schema pattern is specified, we suppress system and temp
      * tables, since they normally aren't very interesting from a 
permissions
      * point of view.  You can see 'em by explicit request though, eg 
with \z
      * pg_catalog.*
      */


So to see the privileges you have to explicitly specify the schema name:

\dp pg_catalog.pg_type
                                      Access privileges
    Schema   |  Name   | Type  |      Access privileges      | Column 
privileges | Policies
------------+---------+-------+-----------------------------+-------------------+----------
  pg_catalog | pg_type | table | =r/postgres +|                   |
             |         |       | 
postgres=arwdDxtvz/postgres+|                   |
             |         |       | alice=vz/postgres |                   |
(1 row)

But perhaps this behavior should be reviewed or at least documented?

-----
Pavel Luzanov



pgsql-hackers by date:

Previous
From: Vik Fearing
Date:
Subject: Re: ANY_VALUE aggregate
Next
From: David Rowley
Date:
Subject: Re: [PoC] Reducing planning time when tables have many partitions