<programlisting>
ALTER TABLE products ALTER COLUMN price TYPE numeric(10,2);
</programlisting>
    This will succeed only if each existing entry in the column can be
    converted to the new type by an implicit cast.  If a more complex
    conversion is needed, you can add a <literal>USING</literal> clause that
    specifies how to compute the new values from the old.
   </para>

   <para>
    <productname>PostgreSQL</productname> will attempt to convert the column's
    default value (if any) to the new type, as well as any constraints
    that involve the column.  But these conversions might fail, or might
    produce surprising results.  It's often best to drop any constraints
    on the column before altering its type, and then add back suitably
    modified constraints afterwards.
   </para>
  </sect2>

  <sect2 id="ddl-alter-renaming-column">
   <title>Renaming a Column</title>

   <indexterm>
    <primary>column</primary>
    <secondary>renaming</secondary>
   </indexterm>

   <para>
    To rename a column:
<programlisting>
ALTER TABLE products RENAME COLUMN product_no TO product_number;
</programlisting>
   </para>
  </sect2>

  <sect2 id="ddl-alter-renaming-table">
   <title>Renaming a Table</title>

   <indexterm>
    <primary>table</primary>
    <secondary>renaming</secondary>
   </indexterm>

   <para>
    To rename a table:
<programlisting>
ALTER TABLE products RENAME TO items;
</programlisting>
   </para>
  </sect2>
 </sect1>

 <sect1 id="ddl-priv">
  <title>Privileges</title>

  <indexterm zone="ddl-priv">
   <primary>privilege</primary>
  </indexterm>

  <indexterm>
   <primary>permission</primary>
   <see>privilege</see>
  </indexterm>

  <indexterm zone="ddl-priv">
   <primary>owner</primary>
  </indexterm>

  <indexterm zone="ddl-priv">
   <primary>GRANT</primary>
  </indexterm>

  <indexterm zone="ddl-priv">
   <primary>REVOKE</primary>
  </indexterm>

  <indexterm zone="ddl-priv">
   <primary><acronym>ACL</acronym></primary>
  </indexterm>

  <indexterm zone="ddl-priv-default">
   <primary>privilege</primary>
   <secondary>default</secondary>
  </indexterm>

  <para>
   When an object is created, it is assigned an owner. The
   owner is normally the role that executed the creation statement.
   For most kinds of objects, the initial state is that only the owner
   (or a superuser) can do anything with the object. To allow
   other roles to use it, <firstterm>privileges</firstterm> must be
   granted.
  </para>

  <para>
   There are different kinds of privileges: <literal>SELECT</literal>,
   <literal>INSERT</literal>, <literal>UPDATE</literal>, <literal>DELETE</literal>,
   <literal>TRUNCATE</literal>, <literal>REFERENCES</literal>, <literal>TRIGGER</literal>,
   <literal>CREATE</literal>, <literal>CONNECT</literal>, <literal>TEMPORARY</literal>,
   <literal>EXECUTE</literal>, <literal>USAGE</literal>, <literal>SET</literal>,
   <literal>ALTER SYSTEM</literal>, and <literal>MAINTAIN</literal>.
   The privileges applicable to a particular
   object vary depending on the object's type (table, function, etc.).
   More detail about the meanings of these privileges appears below.
   The following sections and chapters will also show you how
   these privileges are used.
  </para>

  <para>
   The right to modify or destroy an object is inherent in being the
   object's owner, and cannot be granted or revoked in itself.
   (However, like all privileges, that right can be inherited by
   members of the owning role; see <xref linkend="role-membership"/>.)
  </para>

  <para>
   An object can be assigned to a new owner with an <command>ALTER</command>
   command of the appropriate kind for the object, for example
<programlisting>
ALTER TABLE <replaceable>table_name</replaceable> OWNER TO <replaceable>new_owner</replaceable>;
</programlisting>
   Superusers can always do this; ordinary roles can only do it if they are
   both the current owner of the object (or inherit the privileges of the
   owning role) and able