create_table.sgml

postgresql8.3.4源码,开源数据库

      column constraint or a table constraint.
     </para>

     <para>
      The primary key constraint should name a set of columns that is
      different from other sets of columns named by any unique
      constraint defined for the same table.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>CHECK ( <replaceable class="PARAMETER">expression</replaceable> )</literal></term>
    <listitem>
     <para>
      The <literal>CHECK</> clause specifies an expression producing a
      Boolean result which new or updated rows must satisfy for an
      insert or update operation to succeed.  Expressions evaluating
      to TRUE or UNKNOWN succeed.  Should any row of an insert or
      update operation produce a FALSE result an error exception is
      raised and the insert or update does not alter the database.  A
      check constraint specified as a column constraint should
      reference that column's value only, while an expression
      appearing in a table constraint can reference multiple columns.
     </para>

     <para>
      Currently, <literal>CHECK</literal> expressions cannot contain
      subqueries nor refer to variables other than columns of the
      current row.
     </para>
    </listitem>
   </varlistentry>


   <varlistentry>
    <term><literal>REFERENCES <replaceable class="parameter">reftable</replaceable> [ ( <replaceable class="parameter">refcolumn</replaceable> ) ] [ MATCH <replaceable class="parameter">matchtype</replaceable> ] [ ON DELETE <replaceable class="parameter">action</replaceable> ] [ ON UPDATE <replaceable class="parameter">action</replaceable> ]</literal> (column constraint)</term>

   <term><literal>FOREIGN KEY ( <replaceable class="parameter">column</replaceable> [, ... ] )
    REFERENCES <replaceable class="parameter">reftable</replaceable> [ ( <replaceable class="parameter">refcolumn</replaceable> [, ... ] ) ]
    [ MATCH <replaceable class="parameter">matchtype</replaceable> ]
    [ ON DELETE <replaceable class="parameter">action</replaceable> ]
    [ ON UPDATE <replaceable class="parameter">action</replaceable> ]</literal>
    (table constraint)</term>

    <listitem>
     <para>
      These clauses specify a foreign key constraint, which requires
      that a group of one or more columns of the new table must only
      contain values that match values in the referenced
      column(s) of some row of the referenced table.  If <replaceable
      class="parameter">refcolumn</replaceable> is omitted, the
      primary key of the <replaceable
      class="parameter">reftable</replaceable> is used.  The
      referenced columns must be the columns of a unique or primary
      key constraint in the referenced table.  Note that foreign key
      constraints cannot be defined between temporary tables and
      permanent tables.
     </para>

     <para>
      A value inserted into the referencing column(s) is matched against the
      values of the referenced table and referenced columns using the
      given match type.  There are three match types: <literal>MATCH
      FULL</>, <literal>MATCH PARTIAL</>, and <literal>MATCH
      SIMPLE</literal>, which is also the default.  <literal>MATCH
      FULL</> will not allow one column of a multicolumn foreign key
      to be null unless all foreign key columns are null.
      <literal>MATCH SIMPLE</literal> allows some foreign key columns
      to be null while other parts of the foreign key are not
      null. <literal>MATCH PARTIAL</> is not yet implemented.
     </para>

     <para>
      In addition, when the data in the referenced columns is changed,
      certain actions are performed on the data in this table's
      columns.  The <literal>ON DELETE</literal> clause specifies the
      action to perform when a referenced row in the referenced table is
      being deleted.  Likewise, the <literal>ON UPDATE</literal>
      clause specifies the action to perform when a referenced column
      in the referenced table is being updated to a new value. If the
      row is updated, but the referenced column is not actually
      changed, no action is done. Referential actions other than the
      <literal>NO ACTION</literal> check cannot be deferred, even if
      the constraint is declared deferrable. There are the following possible
      actions for each clause:

      <variablelist>
       <varlistentry>
        <term><literal>NO ACTION</literal></term>
        <listitem>
         <para>
          Produce an error indicating that the deletion or update
          would create a foreign key constraint violation.
          If the constraint is deferred, this
          error will be produced at constraint check time if there still
          exist any referencing rows.  This is the default action.
         </para>
        </listitem>
       </varlistentry>

       <varlistentry>
        <term><literal>RESTRICT</literal></term>
        <listitem>
         <para>
          Produce an error indicating that the deletion or update
          would create a foreign key constraint violation.
          This is the same as <literal>NO ACTION</literal> except that
          the check is not deferrable.
         </para>
        </listitem>
       </varlistentry>

       <varlistentry>
        <term><literal>CASCADE</literal></term>
        <listitem>
         <para>
          Delete any rows referencing the deleted row, or update the
          value of the referencing column to the new value of the
          referenced column, respectively.
         </para>
        </listitem>
       </varlistentry>

       <varlistentry>
        <term><literal>SET NULL</literal></term>
        <listitem>
         <para>
          Set the referencing column(s) to null.
         </para>
        </listitem>
       </varlistentry>

       <varlistentry>
        <term><literal>SET DEFAULT</literal></term>
        <listitem>
         <para>
          Set the referencing column(s) to their default values.
         </para>
        </listitem>
       </varlistentry>
      </variablelist>
     </para>

     <para>
      If the referenced column(s) are changed frequently, it might be wise to
      add an index to the foreign key column so that referential actions
      associated with the foreign key column can be performed more
      efficiently.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>DEFERRABLE</literal></term>
    <term><literal>NOT DEFERRABLE</literal></term>
    <listitem>
     <para>
      This controls whether the constraint can be deferred.  A
      constraint that is not deferrable will be checked immediately
      after every command.  Checking of constraints that are
      deferrable can be postponed until the end of the transaction
      (using the <xref linkend="sql-set-constraints" endterm="sql-set-constraints-title"> command).
      <literal>NOT DEFERRABLE</literal> is the default.  Only foreign
      key constraints currently accept this clause.  All other
      constraint types are not deferrable.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>INITIALLY IMMEDIATE</literal></term>
    <term><literal>INITIALLY DEFERRED</literal></term>
    <listitem>
     <para>
      If a constraint is deferrable, this clause specifies the default
      time to check the constraint.  If the constraint is
      <literal>INITIALLY IMMEDIATE</literal>, it is checked after each
      statement. This is the default.  If the constraint is
      <literal>INITIALLY DEFERRED</literal>, it is checked only at the
      end of the transaction.  The constraint check time can be
      altered with the <xref linkend="sql-set-constraints" endterm="sql-set-constraints-title"> command.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <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"
      endterm="sql-createtable-storage-parameters-title"> for more
      information.  The <literal>WITH</> clause for a
      table can also include <literal>OIDS=TRUE</> (or just <literal>OIDS</>)
      to specify that rows of the new table
      should have OIDs (object identifiers) assigned to them, or
      <literal>OIDS=FALSE</> to specify that the rows should not have OIDs.
      If <literal>OIDS</> is not specified, the default setting depends upon
      the <xref linkend="guc-default-with-oids"> configuration parameter.
      (If the new table inherits from any tables that have OIDs, then
      <literal>OIDS=TRUE</> is forced even if the command says
      <literal>OIDS=FALSE</>.)
     </para>

     <para>
      If <literal>OIDS=FALSE</literal> is specified or implied, the new
      table does not store OIDs and no OID will be assigned for a row inserted
      into it. This is generally considered worthwhile, since it
      will reduce OID consumption and thereby postpone the wraparound
      of the 32-bit OID counter. Once the counter wraps around, OIDs
      can no longer be assumed to be unique, which makes them
      considerably less useful. In addition, excluding OIDs from a
      table reduces the space required to store the table on disk by
      4 bytes per row (on most machines), slightly improving performance.
     </para>

     <para>
      To remove OIDs from a table after it has been created, use <xref
      linkend="sql-altertable" endterm="sql-altertable-title">.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>WITH OIDS</></term>
    <term><literal>WITHOUT OIDS</></term>
    <listitem>
     <para>
      These are obsolescent syntaxes equivalent to <literal>WITH (OIDS)</>
      and <literal>WITH (OIDS=FALSE)</>, respectively.  If you wish to give
      both an <literal>OIDS</> setting and storage parameters, you must use
      the <literal>WITH ( ... )</> syntax; see above.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <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>
        <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>
        <term><literal>DELETE ROWS</literal></term>
        <listitem>
         <para>
          All rows in the temporary table will be deleted at the end
          of each transaction block.  Essentially, an automatic <xref
          linkend="sql-truncate" endterm="sql-truncate-title"> is done
          at each commit.
         </para>
        </listitem>
       </varlistentry>

       <varlistentry>
        <term><literal>DROP</literal></term>
        <listitem>
         <para>
          The temporary table will be dropped at the end of the current
          transaction block.
         </para>
        </listitem>
       </varlistentry>
      </variablelist>
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>TABLESPACE <replaceable class="PARAMETER">tablespace</replaceable></literal></term>
    <listitem>
     <para>
      The <replaceable class="PARAMETER">tablespace</replaceable> is the name
      of the tablespace in which the new table is to be created.
      If not specified,
      <xref linkend="guc-default-tablespace"> is consulted, or
      <xref linkend="guc-temp-tablespaces"> if the table is temporary.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>USING INDEX TABLESPACE <replaceable class="PARAMETER">tablespace</replaceable></literal></term>
    <listitem>
     <para>
      This clause allows selection of the tablespace in which the index
      associated with a <literal>UNIQUE</literal> or <literal>PRIMARY
      KEY</literal> constraint will be created.
      If not specified,
      <xref linkend="guc-default-tablespace"> is consulted, or
      <xref linkend="guc-temp-tablespaces"> if the table is temporary.
     </para>
    </listitem>
   </varlistentry>

  </variablelist>

  <refsect2 id="SQL-CREATETABLE-storage-parameters">
   <title id="SQL-CREATETABLE-storage-parameters-title">Storage Parameters</title>

   <para>
    The <literal>WITH</> clause can specify <firstterm>storage parameters</>
    for tables, and for indexes associated with a <literal>UNIQUE</literal> or
    <literal>PRIMARY KEY</literal> constraint.  Storage parameters for
    indexes are documented in <xref linkend="SQL-CREATEINDEX"
    endterm="sql-createindex-title">.  The only storage parameter currently
    available for tables is:
   </para>

   <variablelist>

   <varlistentry>
    <term><literal>FILLFACTOR</></term>
    <listitem>
     <para>
      The fillfactor for a table is a percentage between 10 and 100.
      100 (complete packing) is the default.  When a smaller fillfactor
      is specified, <command>INSERT</> operations pack table pages only
      to the indicated percentage; the remaining space on each page is
      reserved for updating rows on that page.  This gives <command>UPDATE</>
      a chance to place the updated copy of a row on the same page as the
      original, which is more efficient than placing it on a different page.
      For a table whose entries are never updated, complete packing is the
      best choice, but in heavily updated tables smaller fillfactors are
      appropriate.
     </para>
    </listitem>
   </varlistentry>

   </variablelist>

  </refsect2>
 </refsect1>

 <refsect1 id="SQL-CREATETABLE-notes">
  <title>Notes</title>

    <para>
     Using OIDs in new applications is not recommended: where
     possible, using a <literal>SERIAL</literal> or other sequence
     generator as the table's primary key is preferred. However, if
     your application does make use of OIDs to identify specific
     rows of a table, it is recommended to create a unique constraint
     on the <structfield>oid</> column of that table, to ensure that
     OIDs in the table will indeed uniquely identify rows even after
     counter wraparound.  Avoid assuming that OIDs are unique across
     tables; if you need a database-wide unique identifier, use the
     combination of <structfield>tableoid</> and row OID for the
     purpose.