ALTER DEFAULT PERMISSIONS

The ALTER DEFAULT PERMISSIONS command lets you grant automatic permissions to future objects.

By default, users do not have SELECT permissions on tables created by other users. Database administrators can grant access to other users by modifying the target role default permissions.

For more information about access control, see Access Control.

Permissions

The SUPERUSER permission is required to alter default permissions.

Syntax

The following is the syntax for altering default permissions:

      ALTER DEFAULT PERMISSIONS FOR { "<modifying_role>" | ALL ROLES }
      [ IN "<schema_name>", ...]
      FOR { TABLES | SCHEMAS }
      { <grant_clause> [, ...] | DROP <grant_clause> [, ...] }
      TO { "<role_name>" [, ...] | public };

grant_clause ::=
   GRANT
      { SUPERUSER
      | CREATE
      | USAGE
      | SELECT
      | UPDATE
      | DDL
      | ALL
      } [, ...]

Supported Permissions

The following table describes the supported permissions:

Permission

Object

Description

SUPERUSER

Schema

The most privileged role, with full control over a cluster, database, or schema

CREATE

Schema

For a role to create and manage objects, it needs the CREATE and USAGE permissions at the respective level

USAGE

Schema

For a role to see tables in a schema, it needs the USAGE permissions

SELECT

Table

Allows a user to run SELECT queries on table contents

INSERT

Table

Allows a user to run COPY FROM and INSERT statements to load data into a table

UPDATE

Table

Allows a user to modify the value of certain columns in existing rows without creating a table

DELETE

Table

Allows a user to run DELETE, TRUNCATE statements to delete data from a table

DDL

Schema, Table

Allows a user to alter tables, rename columns and tables, etc.

Examples

Granting Default Table Permissions

This example is based on the roles r1 and r2, created as follows:

CREATE ROLE r1;
CREATE ROLE r2;
ALTER DEFAULT PERMISSIONS FOR r1 FOR TABLES GRANT SELECT to r2;

Once created, you can build and run the following query based on the above:

SELECT
  tdp.database_name AS "database_name",
  ss.schema_name AS "schema_name",
  rs1.name AS "table_creator",
  rs2.name AS "grant_to",
  pts.name  AS "permission_type"
FROM sqream_catalog.table_default_permissions tdp
INNER JOIN sqream_catalog.roles rs1 ON tdp.modifier_role_id = rs1.role_id
INNER JOIN sqream_catalog.roles rs2 ON tdp.getter_role_id = rs2.role_id
LEFT JOIN sqream_catalog.schemas ss ON tdp.schema_id = ss.schema_id
INNER JOIN sqream_catalog.permission_types pts ON pts.permission_type_id=tdp.permission_type
;

Output:

database_name | schema_name | table_creator | grant_to | permission_type
--------------+-------------+---------------+----------+----------------
master        |   NULL      | public        | public   | select

Granting Automatic Permissions for Newly Created Schemas

When the role demo creates a new schema, roles u1,u2 are granted USAGE and CREATE permissions in the new schema, as shown below:

ALTER DEFAULT PERMISSIONS FOR demo FOR SCHEMAS GRANT USAGE, CREATE TO u1,u2;

Granting Automatic Permissions for Newly Created Tables in a Schema

When the role demo creates a new table in schema s1, roles u1,u2 are granted SELECT permissions, as shown below:

ALTER DEFAULT PERMISSIONS FOR demo IN s1 FOR TABLES GRANT SELECT TO u1,u2;

Revoking Permissions from Newly Created Tables

Revoking permissions refers to using the DROP GRANT command, as shown below:

ALTER DEFAULT PERMISSIONS FOR public FOR TABLES DROP GRANT SELECT,DDL TO public;