Skip to content

Commit e5df9bb

Browse files
committed
Doc: clarify behavior of ALTER DEFAULT PRIVILEGES ... IN SCHEMA.
The existing text stated that "Default privileges that are specified per-schema are added to whatever the global default privileges are for the particular object type". However, that bare-bones observation is not quite clear enough, as demonstrated by the complaint in bug #16124. Flesh it out by stating explicitly that you can't revoke built-in default privileges this way, and by providing an example to drive the point home. Back-patch to all supported branches, since it's been like this from the beginning. Discussion: https://postgr.es/m/16124-423d8ee4358421bc@postgresql.org
1 parent 65da6dd commit e5df9bb

File tree

1 file changed

+22
-6
lines changed

1 file changed

+22
-6
lines changed

doc/src/sgml/ref/alter_default_privileges.sgml

Lines changed: 22 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -89,9 +89,7 @@ REVOKE [ GRANT OPTION FOR ]
8989
You can change default privileges only for objects that will be created by
9090
yourself or by roles that you are a member of. The privileges can be set
9191
globally (i.e., for all objects created in the current database),
92-
or just for objects created in specified schemas. Default privileges
93-
that are specified per-schema are added to whatever the global default
94-
privileges are for the particular object type.
92+
or just for objects created in specified schemas.
9593
</para>
9694

9795
<para>
@@ -103,6 +101,16 @@ REVOKE [ GRANT OPTION FOR ]
103101
<command>ALTER DEFAULT PRIVILEGES</>.
104102
</para>
105103

104+
<para>
105+
Default privileges that are specified per-schema are added to whatever
106+
the global default privileges are for the particular object type.
107+
This means you cannot revoke privileges per-schema if they are granted
108+
globally (either by default, or according to a previous <command>ALTER
109+
DEFAULT PRIVILEGES</command> command that did not specify a schema).
110+
Per-schema <literal>REVOKE</literal> is only useful to reverse the
111+
effects of a previous per-schema <literal>GRANT</literal>.
112+
</para>
113+
106114
<refsect2>
107115
<title>Parameters</title>
108116

@@ -193,11 +201,19 @@ ALTER DEFAULT PRIVILEGES IN SCHEMA myschema REVOKE INSERT ON TABLES FROM webuser
193201

194202
<para>
195203
Remove the public EXECUTE permission that is normally granted on functions,
196-
for all functions subsequently created by role <literal>admin</>:
197-
204+
for all functions subsequently created by role <literal>admin</literal>:
198205
<programlisting>
199206
ALTER DEFAULT PRIVILEGES FOR ROLE admin REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC;
200-
</programlisting></para>
207+
</programlisting>
208+
Note however that you <emphasis>cannot</emphasis> accomplish that effect
209+
with a command limited to a single schema. This command has no effect,
210+
unless it is undoing a matching <literal>GRANT</literal>:
211+
<programlisting>
212+
ALTER DEFAULT PRIVILEGES IN SCHEMA public REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC;
213+
</programlisting>
214+
That's because per-schema default privileges can only add privileges to
215+
the global setting, not remove privileges granted by it.
216+
</para>
201217
</refsect1>
202218

203219
<refsect1>

0 commit comments

Comments
 (0)