commented.
  </para>

  <para>
   For most kinds of object, only the object's owner can set the comment.
   Roles don't have owners, so the rule for <literal>COMMENT ON ROLE</literal> is
   that you must be superuser to comment on a superuser role, or have the
   <literal>CREATEROLE</literal> privilege and have been granted
   <literal>ADMIN OPTION</literal> on the target role.
   Likewise, access methods don't have owners either; you must be superuser
   to comment on an access method.
   Of course, a superuser can comment on anything.
  </para>

  <para>
    Comments can be viewed using <application>psql</application>'s
    <command>\d</command> family of commands.
    Other user interfaces to retrieve comments can be built atop
    the same built-in functions that <application>psql</application> uses, namely
    <function>obj_description</function>, <function>col_description</function>,
    and <function>shobj_description</function>
    (see <xref linkend="functions-info-comment-table"/>).
  </para>
 </refsect1>

 <refsect1>
  <title>Parameters</title>

  <variablelist>
   <varlistentry>
    <term><replaceable class="parameter">object_name</replaceable></term>
    <term><replaceable class="parameter">relation_name</replaceable>.<replaceable>column_name</replaceable></term>
    <term><replaceable class="parameter">aggregate_name</replaceable></term>
    <term><replaceable class="parameter">constraint_name</replaceable></term>
    <term><replaceable class="parameter">function_name</replaceable></term>
    <term><replaceable class="parameter">operator_name</replaceable></term>
    <term><replaceable class="parameter">policy_name</replaceable></term>
    <term><replaceable class="parameter">procedure_name</replaceable></term>
    <term><replaceable class="parameter">routine_name</replaceable></term>
    <term><replaceable class="parameter">rule_name</replaceable></term>
    <term><replaceable class="parameter">trigger_name</replaceable></term>
    <listitem>
     <para>
      The name of the object to be commented.  Names of objects that reside in
      schemas (tables, functions, etc.) can be
      schema-qualified. When commenting on a column,
      <replaceable class="parameter">relation_name</replaceable> must refer
      to a table, view, composite type, or foreign table.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">table_name</replaceable></term>
    <term><replaceable class="parameter">domain_name</replaceable></term>
    <listitem>
     <para>
      When creating a comment on a constraint, a trigger, a rule or
      a policy these parameters specify the name of the table or domain on
      which that object is defined.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
     <term><replaceable>source_type</replaceable></term>
     <listitem>
      <para>
       The name of the source data type of the cast.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><replaceable>target_type</replaceable></term>
     <listitem>
      <para>
       The name of the target data type of the cast.
      </para>
     </listitem>
    </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">argmode</replaceable></term>
    <listitem>
     <para>
      The mode of a function, procedure, or aggregate
      argument: <literal>IN</literal>, <literal>OUT</literal>,
      <literal>INOUT</literal>, or <literal>VARIADIC</literal>.
      If omitted, the default is <literal>IN</literal>.
      Note that <command>COMMENT</command> does not actually pay
      any attention to <literal>OUT</literal> arguments, since only the input
      arguments are needed to determine the function's identity.
      So it is sufficient to list the <literal>IN</literal>, <literal>INOUT</literal>,
      and <literal>VARIADIC</literal> arguments.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">argname</replaceable></term>