either are a primary key or
    form a unique constraint, or are columns from a non-partial unique index.
    This means that the referenced columns always have an index to allow
    efficient lookups on whether a referencing row has a match.  Since a
    <command>DELETE</command> of a row from the referenced table or an
    <command>UPDATE</command> of a referenced column will require a scan of
    the referencing table for rows matching the old value, it is often a good
    idea to index the referencing columns too.  Because this is not always
    needed, and there are many choices available on how to index, the
    declaration of a foreign key constraint does not automatically create an
    index on the referencing columns.
   </para>

   <para>
    More information about updating and deleting data is in <xref
    linkend="dml"/>.  Also see the description of foreign key constraint
    syntax in the reference documentation for
    <xref linkend="sql-createtable"/>.
   </para>
  </sect2>

  <sect2 id="ddl-constraints-exclusion">
   <title>Exclusion Constraints</title>

   <indexterm>
    <primary>exclusion constraint</primary>
   </indexterm>

   <indexterm>
    <primary>constraint</primary>
    <secondary>exclusion</secondary>
   </indexterm>

   <para>
    Exclusion constraints ensure that if any two rows are compared on
    the specified columns or expressions using the specified operators,
    at least one of these operator comparisons will return false or null.
    The syntax is:
<programlisting>
CREATE TABLE circles (
    c circle,
    EXCLUDE USING gist (c WITH &amp;&amp;)
);
</programlisting>
   </para>

   <para>
    See also <link linkend="sql-createtable-exclude"><command>CREATE
    TABLE ... CONSTRAINT ... EXCLUDE</command></link> for details.
   </para>

   <para>
    Adding an exclusion constraint will automatically create an index
    of the type specified in the constraint declaration.
   </para>
  </sect2>
 </sect1>

 <sect1 id="ddl-system-columns">
  <title>System Columns</title>

  <para>
   Every table has several <firstterm>system columns</firstterm> that are
   implicitly defined by the system.  Therefore, these names cannot be
   used as names of user-defined columns.  (Note that these
   restrictions are separate from whether the name is a key word or
   not; quoting a name will not allow you to escape these
   restrictions.)  You do not really need to be concerned about these
   columns; just know they exist.
  </para>

  <indexterm>
   <primary>column</primary>
   <secondary>system column</secondary>
  </indexterm>

  <variablelist>
   <varlistentry id="ddl-system-columns-tableoid">
    <term><structfield>tableoid</structfield></term>
    <listitem>
     <indexterm>
      <primary>tableoid</primary>
     </indexterm>

     <para>
      The OID of the table containing this row.  This column is
      particularly handy for queries that select from partitioned
      tables (see <xref linkend="ddl-partitioning"/>) or inheritance
      hierarchies (see <xref linkend="ddl-inherit"/>), since without it,
      it's difficult to tell which individual table a row came from.  The
      <structfield>tableoid</structfield> can be joined against the
      <structfield>oid</structfield> column of
      <structname>pg_class</structname> to obtain the table name.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry id="ddl-system-columns-xmin">
    <term><structfield>xmin</structfield></term>
    <listitem>
     <indexterm>
      <primary>xmin</primary>
     </indexterm>

     <para>
      The identity (transaction ID) of the inserting transaction for
      this row version.  (A row version is an individual state of a
      row; each update of a row creates a new row version for the same
      logical row.)
     </para>
    </listitem>
   </varlistentry>

   <varlistentry id="ddl-system-columns-cmin">
    <term><structfield>cmin</structfield></term>
    <listitem>
     <indexterm>
      <primary>cmin</primary>