ALTER_DEFAULT_PRIVILEGES(7pg13)

✨ ALTER_DEFAULT_PRIVILEGES 💅 — the ALTER DEFAULT PRIVILEGES manual page (PostgreSQL 13.23, 7pg13 bestie, iykyk)

okay so quick vibe check: this is the page for ALTER_DEFAULT_PRIVILEGES, and it's genuinely one of the most underrated glow-ups in Postgres. it's giving "set it and forget it" but for permissions. let's go 🫶

---

✨ NAME ✨

ALTER_DEFAULT_PRIVILEGES — literally the command that defines your default access privileges. periodt. 💖

---

🎀 SYNOPSIS 🎀

ALTER DEFAULT PRIVILEGES
    [ FOR { ROLE | USER } target_role [, ...] ]
    [ IN SCHEMA schema_name [, ...] ]
    abbreviated_grant_or_revoke

where abbreviated_grant_or_revoke is one of these bad boys:

GRANT { { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER }
    [, ...] | ALL [ PRIVILEGES ] }
    ON TABLES
    TO { [ GROUP ] role_name | PUBLIC } [, ...] [ WITH GRANT OPTION ]

GRANT { { USAGE | SELECT | UPDATE }
    [, ...] | ALL [ PRIVILEGES ] }
    ON SEQUENCES
    TO { [ GROUP ] role_name | PUBLIC } [, ...] [ WITH GRANT OPTION ]

GRANT { EXECUTE | ALL [ PRIVILEGES ] }
    ON { FUNCTIONS | ROUTINES }
    TO { [ GROUP ] role_name | PUBLIC } [, ...] [ WITH GRANT OPTION ]

GRANT { USAGE | ALL [ PRIVILEGES ] }
    ON TYPES
    TO { [ GROUP ] role_name | PUBLIC } [, ...] [ WITH GRANT OPTION ]

GRANT { { USAGE | CREATE }
    [, ...] | ALL [ PRIVILEGES ] }
    ON SCHEMAS
    TO { [ GROUP ] role_name | PUBLIC } [, ...] [ WITH GRANT OPTION ]

REVOKE [ GRANT OPTION FOR ]
    { { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER }
    [, ...] | ALL [ PRIVILEGES ] }
    ON TABLES
    FROM { [ GROUP ] role_name | PUBLIC } [, ...]
    [ CASCADE | RESTRICT ]

REVOKE [ GRANT OPTION FOR ]
    { { USAGE | SELECT | UPDATE }
    [, ...] | ALL [ PRIVILEGES ] }
    ON SEQUENCES
    FROM { [ GROUP ] role_name | PUBLIC } [, ...]
    [ CASCADE | RESTRICT ]

REVOKE [ GRANT OPTION FOR ]
    { EXECUTE | ALL [ PRIVILEGES ] }
    ON { FUNCTIONS | ROUTINES }
    FROM { [ GROUP ] role_name | PUBLIC } [, ...]
    [ CASCADE | RESTRICT ]

REVOKE [ GRANT OPTION FOR ]
    { USAGE | ALL [ PRIVILEGES ] }
    ON TYPES
    FROM { [ GROUP ] role_name | PUBLIC } [, ...]
    [ CASCADE | RESTRICT ]

REVOKE [ GRANT OPTION FOR ]
    { { USAGE | CREATE }
    [, ...] | ALL [ PRIVILEGES ] }
    ON SCHEMAS
    FROM { [ GROUP ] role_name | PUBLIC } [, ...]
    [ CASCADE | RESTRICT ]

yes bestie, that's a lot of syntax. no, you cannot skip it. it's all load-bearing. 💀

---

🦋 DESCRIPTION 🦋

so what does ALTER DEFAULT PRIVILEGES actually do? it lets you set the privileges that get applied to objects created in the future. future-you's objects. main character energy for objects that don't even exist yet, honestly. ✨

careful though: it does not affect privileges assigned to already-existing objects. those are set in stone (well, in the catalog) and you gotta go fix them separately.

right now, the only object types whose privileges you can alter here are: schemas, tables (and that includes views and foreign tables), sequences, functions, and types (including domains). 🎀

for this command specifically, "functions" is a wide net — it includes aggregates and procedures too. and the words FUNCTIONS and ROUTINES are equivalent in this command. like, literally the same thing, no cap.

a lil note from the future: ROUTINES is preferred going forward, since it's the standard term for functions and procedures taken together. in earlier PostgreSQL releases, only the word FUNCTIONS was allowed. and ngl, it is not possible to set default privileges for functions and procedures separately. they're a package deal. 💜

you can only change default privileges for objects that will be created by yourself or by roles that you are a member of. that's the whole rule. no setting defaults on behalf of strangers. 🙈

and you can set them two ways:

• globally — i.e. for all objects created in the current database
• per-schema — just for objects created in schemas you name

as explained in Section 5.7, the default privileges for any object type normally grant all grantable permissions to the object owner, and may grant some privileges to PUBLIC as well. but that behavior can be changed by altering the global default privileges with ALTER DEFAULT PRIVILEGES. so yeah, you can rewrite the rules. 👑

okay here's the part that trips literally everyone, so pay attention bestie:

per-schema default privileges get added to whatever the global default privileges are for that object type. that means you cannot revoke privileges per-schema if they're granted globally — whether that global grant comes from the default, or from a previous ALTER DEFAULT PRIVILEGES command that didn't specify a schema. per-schema REVOKE is only useful to reverse the effects of a previous per-schema GRANT. that's it. that's the whole job. 😭

💅 Parameters

• target_role — the name of an existing role of which the current role is a member. and listen: default access privileges are not inherited, so member roles must use SET ROLE to access these privileges, or ALTER DEFAULT PRIVILEGES must be run for each member role. doing it once for the parent does not cover the children, sorry. if FOR ROLE is omitted, the current role is assumed. 🫶
• schema_name — the name of an existing schema. if specified, the default privileges are altered for objects later created in that schema. if IN SCHEMA is omitted, the global default privileges are altered. also, IN SCHEMA is not allowed when setting privileges for schemas, because schemas can't be nested. we don't do schema-ception here. 🚫
• role_name — the name of an existing role to grant or revoke privileges for. this parameter, and all the other parameters in abbreviated_grant_or_revoke, act as described under GRANT(7) or REVOKE(7) — except that you're setting permissions for a whole class of objects rather than specific named objects. big-picture queen behavior. 🌈

---

🔥 NOTES 🔥

use psql(1)'s \ddp command to get info about existing assignments of default privileges. the meaning of the privilege display is the same as explained for \dp in Section 5.7. so if you already know \dp, you already know. iykyk. ⭐

plot twist warning: if you wish to drop a role for which the default privileges have been altered, it is necessary to reverse the changes in its default privileges or use DROP OWNED BY to get rid of the default privileges entry for the role. you can't just drop it and vibe. the entry will haunt you. 💀

---

🌸 EXAMPLES 🌸

grant it 💖

grant SELECT privilege to everyone for all tables (and views) you subsequently create in schema myschema, and allow role webuser to INSERT into them too:

ALTER DEFAULT PRIVILEGES IN SCHEMA myschema GRANT SELECT ON TABLES TO PUBLIC;
ALTER DEFAULT PRIVILEGES IN SCHEMA myschema GRANT INSERT ON TABLES TO webuser;

undo it 🙈

undo the above, so that subsequently-created tables won't have any more permissions than normal:

ALTER DEFAULT PRIVILEGES IN SCHEMA myschema REVOKE SELECT ON TABLES FROM PUBLIC;
ALTER DEFAULT PRIVILEGES IN SCHEMA myschema REVOKE INSERT ON TABLES FROM webuser;

the fun one 😭

remove the public EXECUTE permission that is normally granted on functions, for all functions subsequently created by role admin:

ALTER DEFAULT PRIVILEGES FOR ROLE admin REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC;

note however that you cannot accomplish that effect with a command limited to a single schema. this command has no effect, unless it is undoing a matching GRANT:

ALTER DEFAULT PRIVILEGES IN SCHEMA public REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC;

that's because per-schema default privileges can only add privileges to the global setting, not remove privileges granted by it. it's an adder, not a subtractor. it's giving "yes and", never "actually no". 💅✨

---

👑 COMPATIBILITY 👑

there is no ALTER DEFAULT PRIVILEGES statement in the SQL standard. we're built different. 🦋

---

🎀 SEE ALSO 🎀

• GRANT(7)
• REVOKE(7)

---

that's the whole page bestie, go forth and set some defaults responsibly. 🍓

PostgreSQL 13.23 — 2025 — ALTER DEF...RIVILEGES(7) 💜 (yes the title got truncated in the header, no we're not fixing it, it's canon now)