grant or deny this permission based on the
    client's security label and the proposed security label for the new
    object.  In some cases, additional privileges are required:
   </para>

   <itemizedlist>
    <listitem>
     <para>
      <link linkend="sql-createdatabase"><command>CREATE DATABASE</command></link> additionally requires
      <literal>getattr</literal> permission for the source or template database.
     </para>
    </listitem>
    <listitem>
     <para>
      Creating a schema object additionally requires <literal>add_name</literal>
      permission on the parent schema.
     </para>
    </listitem>
    <listitem>
     <para>
      Creating a table additionally requires permission to create each
      individual table column, just as if each table column were a
      separate top-level object.
     </para>
    </listitem>
    <listitem>
     <para>
      Creating a function marked as <literal>LEAKPROOF</literal> additionally
      requires <literal>install</literal> permission.  (This permission is also
      checked when <literal>LEAKPROOF</literal> is set for an existing function.)
     </para>
    </listitem>
   </itemizedlist>

   <para>
    When <literal>DROP</literal> command is executed, <literal>drop</literal> will be
    checked on the object being removed.  Permissions will be also checked for
    objects dropped indirectly via <literal>CASCADE</literal>.  Deletion of objects
    contained within a particular schema (tables, views, sequences and
    procedures) additionally requires <literal>remove_name</literal> on the schema.
   </para>

   <para>
    When <literal>ALTER</literal> command is executed, <literal>setattr</literal> will be
    checked on the object being modified for each object types, except for
    subsidiary objects such as the indexes or triggers of a table, where
    permissions are instead checked on the parent object.  In some cases,
    additional permissions are required:
   </para>

   <itemizedlist>
    <listitem>
     <para>
      Moving an object to a new schema additionally requires
      <literal>remove_name</literal> permission on the old schema and
      <literal>add_name</literal> permission on the new one.
     </para>
    </listitem>
    <listitem>
     <para>
      Setting the <literal>LEAKPROOF</literal> attribute on a function requires
      <literal>install</literal> permission.
     </para>
    </listitem>
    <listitem>
     <para>
      Using <link linkend="sql-security-label"><command>SECURITY LABEL</command></link> on an object additionally
      requires <literal>relabelfrom</literal> permission for the object in
      conjunction with its old security label and <literal>relabelto</literal>
      permission for the object in conjunction with its new security label.
      (In cases where multiple label providers are installed and the user
      tries to set a security label, but it is not managed by
      <productname>SELinux</productname>, only <literal>setattr</literal> should be checked here.
      This is currently not done due to implementation restrictions.)
     </para>
    </listitem>
   </itemizedlist>

  </sect3>

  <sect3 id="sepgsql-features-trusted-procedures">
   <title>Trusted Procedures</title>
   <para>
    Trusted procedures are similar to security definer functions or setuid
    commands. <productname>SELinux</productname> provides a feature to allow trusted
    code to run using a security label different from that of the client,
    generally for the purpose of providing highly controlled access to
    sensitive data (e.g., rows might be omitted, or the precision of stored
    values might be reduced).  Whether or not a function acts as a trusted
    procedure is controlled by its security label and the operating system
    security policy.  For example:
   </para>

<screen>
postgres=# CREATE TABLE customer (
               cid     int primary key,
               cname   text,
               credit  text
           );
CREATE TABLE
postgres=#