You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
Doc: fix old oversights in GRANT/REVOKE documentation.
The GRANTED BY clause in GRANT/REVOKE ROLE has been there since 2005but was never documented. I'm not sure now whether that was just anoversight or was intentional (given the limited capability of theoption). But seeing that pg_dumpall does emit code that uses thisoption, it seems like not documenting it at all is a bad idea.Also, when we upgraded the syntax to allow CURRENT_USER/SESSION_USERas the privilege recipient, the role form of GRANT was incorrectlynot modified to show that, and REVOKE's docs weren't touched at all.Although I'm not that excited about GRANTED BY, the other oversightseems serious enough to justify a back-patch.Discussion:https://postgr.es/m/3070.1581526786@sss.pgh.pa.us
Copy file name to clipboardExpand all lines: doc/src/sgml/ref/grant.sgml
+20-4Lines changed: 20 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -79,14 +79,16 @@ GRANT { USAGE | ALL [ PRIVILEGES ] }
79
79
ON TYPE <replaceable>type_name</replaceable> [, ...]
80
80
TO <replaceable class="PARAMETER">role_specification</replaceable> [, ...] [ WITH GRANT OPTION ]
81
81
82
+
GRANT <replaceable class="PARAMETER">role_name</replaceable> [, ...] TO <replaceable class="PARAMETER">role_specification</replaceable> [, ...]
83
+
[ WITH ADMIN OPTION ]
84
+
[ GRANTED BY <replaceable class="PARAMETER">role_specification</replaceable> ]
85
+
82
86
<phrase>where <replaceable class="PARAMETER">role_specification</replaceable> can be:</phrase>
83
87
84
88
[ GROUP ] <replaceable class="PARAMETER">role_name</replaceable>
85
89
| PUBLIC
86
90
| CURRENT_USER
87
91
| SESSION_USER
88
-
89
-
GRANT <replaceable class="PARAMETER">role_name</replaceable> [, ...] TO <replaceable class="PARAMETER">role_name</replaceable> [, ...] [ WITH ADMIN OPTION ]
90
92
</synopsis>
91
93
</refsynopsisdiv>
92
94
@@ -420,10 +422,17 @@ GRANT <replaceable class="PARAMETER">role_name</replaceable> [, ...] TO <replace
420
422
or revoke membership in any role that is not a superuser.
421
423
</para>
422
424
425
+
<para>
426
+
If <literal>GRANTED BY</literal> is specified, the grant is recorded as
427
+
having been done by the specified role. Only database superusers may
428
+
use this option, except when it names the same role executing the command.
429
+
</para>
430
+
423
431
<para>
424
432
Unlike the case with privileges, membership in a role cannot be granted
425
-
to <literal>PUBLIC</>. Note also that this form of the command does not
426
-
allow the noise word <literal>GROUP</>.
433
+
to <literal>PUBLIC</literal>. Note also that this form of the command
434
+
does not allow the noise word <literal>GROUP</literal>
435
+
in <replaceable class="parameter">role_specification</replaceable>.
427
436
</para>
428
437
</refsect2>
429
438
</refsect1>
@@ -653,6 +662,13 @@ GRANT admins TO joe;
653
662
to roles.
654
663
</para>
655
664
665
+
<para>
666
+
The SQL standard allows the <literal>GRANTED BY</literal> option to
667
+
be used in all forms of <command>GRANT</command>. PostgreSQL only
668
+
supports it when granting role membership, and even then only superusers
669
+
may use it in nontrivial ways.
670
+
</para>
671
+
656
672
<para>
657
673
The SQL standard provides for a <literal>USAGE</literal> privilege
658
674
on other kinds of objects: character sets, collations,