Home • Explore • Blog • CI
☰



postgresql
7th chunk of `doc/src/sgml/ref/grant.sgml`
e8941e40d11f75085c38888ece4677d358d5cc4eec0158260000000100000aa7
 granted by the object owner.
    (For role membership, the membership appears to have been granted
    by the bootstrap superuser.)
   </para>

   <para>
    <command>GRANT</command> and <command>REVOKE</command> can also be done by a role
    that is not the owner of the affected object, but is a member of the role
    that owns the object, or is a member of a role that holds privileges
    <literal>WITH GRANT OPTION</literal> on the object.  In this case the
    privileges will be recorded as having been granted by the role that
    actually owns the object or holds the privileges
    <literal>WITH GRANT OPTION</literal>.  For example, if table
    <literal>t1</literal> is owned by role <literal>g1</literal>, of which role
    <literal>u1</literal> is a member, then <literal>u1</literal> can grant privileges
    on <literal>t1</literal> to <literal>u2</literal>, but those privileges will appear
    to have been granted directly by <literal>g1</literal>.  Any other member
    of role <literal>g1</literal> could revoke them later.
   </para>

   <para>
    If the role executing <command>GRANT</command> holds the required privileges
    indirectly via more than one role membership path, it is unspecified
    which containing role will be recorded as having done the grant.  In such
    cases it is best practice to use <command>SET ROLE</command> to become the
    specific role you want to do the <command>GRANT</command> as.
   </para>

   <para>
    Granting permission on a table does not automatically extend
    permissions to any sequences used by the table, including
    sequences tied to <type>SERIAL</type> columns.  Permissions on
    sequences must be set separately.
   </para>

   <para>
    See <xref linkend="ddl-priv"/> for more information about specific
    privilege types, as well as how to inspect objects' privileges.
   </para>
 </refsect1>

 <refsect1 id="sql-grant-examples">
  <title>Examples</title>

  <para>
   Grant insert privilege to all users on table <literal>films</literal>:

<programlisting>
GRANT INSERT ON films TO PUBLIC;
</programlisting>
  </para>

  <para>
   Grant all available privileges to user <literal>manuel</literal> on view
   <literal>kinds</literal>:

<programlisting>
GRANT ALL PRIVILEGES ON kinds TO manuel;
</programlisting>

   Note that while the above will indeed grant all privileges if executed by a
   superuser or the owner of <literal>kinds</literal>, when executed by someone
   else it will only grant those permissions for which the someone else has
   grant options.
  </para>

  <para>
   Grant membership in role <literal>admins</literal> to user <literal>joe</literal>:

<programlisting>
GRANT admins TO joe;
</programlisting></para>
Title: GRANT Command: Additional Notes, Examples, and Sequence Permissions
Summary
This section continues the notes on the GRANT command, detailing how privileges are recorded when granted through role memberships, the ambiguity when multiple membership paths exist, the need to explicitly grant permissions on sequences used by tables, and providing examples of granting insert privilege to all users, all available privileges to a specific user, and membership in a role to a user. It emphasizes best practices and directs the reader to further information on privilege types.