the transaction.  The constraint check time can be
      altered with the <link linkend="sql-set-constraints"><command>SET CONSTRAINTS</command></link> command.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry id="sql-createtable-parms-enforced">
    <term><literal>ENFORCED</literal></term>
    <term><literal>NOT ENFORCED</literal></term>
    <listitem>
     <para>
      When the constraint is <literal>ENFORCED</literal>, then the database
      system will ensure that the constraint is satisfied, by checking the
      constraint at appropriate times (after each statement or at the end of
      the transaction, as appropriate).  That is the default.  If the
      constraint is <literal>NOT ENFORCED</literal>, the database system will
      not check the constraint.  It is then up to the application code to
      ensure that the constraints are satisfied.  The database system might
      still assume that the data actually satisfies the constraint for
      optimization decisions where this does not affect the correctness of the
      result.
     </para>

     <para>
      <literal>NOT ENFORCED</literal> constraints can be useful as
      documentation if the actual checking of the constraint at run time is
      too expensive.
     </para>

     <para>
      This is currently only supported for foreign key and <literal>CHECK</literal>
      constraints.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry id="sql-createtable-method">
    <term><literal>USING <replaceable class="parameter">method</replaceable></literal></term>
    <listitem>
     <para>
      This optional clause specifies the table access method to use to store
      the contents for the new table; the method needs be an access method of
      type <literal>TABLE</literal>. See <xref linkend="tableam"/> for more
      information.  If this option is not specified, the default table access
      method is chosen for the new table. See <xref
      linkend="guc-default-table-access-method"/> for more information.
     </para>
     <para>
      When creating a partition, the table access method is the access method
      of its partitioned table, if set.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry id="sql-createtable-parms-with">
    <term><literal>WITH ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] )</literal></term>
    <listitem>
     <para>
      This clause specifies optional storage parameters for a table or index;
      see <xref linkend="sql-createtable-storage-parameters"/> below for more
      information.  For backward-compatibility the <literal>WITH</literal>
      clause for a table can also include <literal>OIDS=FALSE</literal> to
      specify that rows of the new table should not contain OIDs (object
      identifiers), <literal>OIDS=TRUE</literal> is not supported anymore.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry id="sql-createtable-parms-without-oids">
    <term><literal>WITHOUT OIDS</literal></term>
    <listitem>
     <para>
      This is backward-compatible syntax for declaring a table
      <literal>WITHOUT OIDS</literal>, creating a table <literal>WITH
      OIDS</literal> is not supported anymore.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry id="sql-createtable-parms-on-commit">
    <term><literal>ON COMMIT</literal></term>
    <listitem>
     <para>
      The behavior of temporary tables at the end of a transaction
      block can be controlled using <literal>ON COMMIT</literal>.
      The three options are:

      <variablelist>
       <varlistentry id="sql-createtable-parms-on-commit-preserve-rows">
        <term><literal>PRESERVE ROWS</literal></term>
        <listitem>
         <para>
          No special action is taken at the ends of transactions.
          This is the default behavior.
         </para>
        </listitem>
       </varlistentry>

       <varlistentry