field or variable of
    the domain type is allowed without writing an explicit cast, but the
    domain's constraints will be checked.
   </para>

   <para>
    For additional information see <xref linkend="sql-createdomain"/>.
   </para>
  </sect1>

  <sect1 id="datatype-oid">
   <title>Object Identifier Types</title>

   <indexterm zone="datatype-oid">
    <primary>object identifier</primary>
    <secondary>data type</secondary>
   </indexterm>

   <indexterm zone="datatype-oid">
    <primary>oid</primary>
   </indexterm>

   <indexterm zone="datatype-oid">
    <primary>regclass</primary>
   </indexterm>

   <indexterm zone="datatype-oid">
    <primary>regcollation</primary>
   </indexterm>

   <indexterm zone="datatype-oid">
    <primary>regconfig</primary>
   </indexterm>

   <indexterm zone="datatype-oid">
    <primary>regdictionary</primary>
   </indexterm>

   <indexterm zone="datatype-oid">
    <primary>regnamespace</primary>
   </indexterm>

   <indexterm zone="datatype-oid">
    <primary>regoper</primary>
   </indexterm>

   <indexterm zone="datatype-oid">
    <primary>regoperator</primary>
   </indexterm>

   <indexterm zone="datatype-oid">
    <primary>regproc</primary>
   </indexterm>

   <indexterm zone="datatype-oid">
    <primary>regprocedure</primary>
   </indexterm>

   <indexterm zone="datatype-oid">
    <primary>regrole</primary>
   </indexterm>

   <indexterm zone="datatype-oid">
    <primary>regtype</primary>
   </indexterm>

   <indexterm zone="datatype-oid">
    <primary>xid8</primary>
   </indexterm>

   <indexterm zone="datatype-oid">
    <primary>cid</primary>
   </indexterm>

   <indexterm zone="datatype-oid">
    <primary>tid</primary>
   </indexterm>

   <indexterm zone="datatype-oid">
    <primary>xid</primary>
   </indexterm>

   <para>
    Object identifiers (OIDs) are used internally by
    <productname>PostgreSQL</productname> as primary keys for various
    system tables.
    Type <type>oid</type> represents an object identifier.  There are also
    several alias types for <type>oid</type>, each
    named <type>reg<replaceable>something</replaceable></type>.
    <xref linkend="datatype-oid-table"/> shows an
    overview.
   </para>

   <para>
    The <type>oid</type> type is currently implemented as an unsigned
    four-byte integer.  Therefore, it is not large enough to provide
    database-wide uniqueness in large databases, or even in large
    individual tables.
   </para>

   <para>
    The <type>oid</type> type itself has few operations beyond comparison.
    It can be cast to integer, however, and then manipulated using the
    standard integer operators.  (Beware of possible
    signed-versus-unsigned confusion if you do this.)
   </para>

   <para>
    The OID alias types have no operations of their own except
    for specialized input and output routines.  These routines are able
    to accept and display symbolic names for system objects, rather than
    the raw numeric value that type <type>oid</type> would use.  The alias
    types allow simplified lookup of OID values for objects.  For example,
    to examine the <structname>pg_attribute</structname> rows related to a table
    <literal>mytable</literal>, one could write:
<programlisting>
SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;
</programlisting>
    rather than:
<programlisting>
SELECT * FROM pg_attribute
  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');
</programlisting>
    While that doesn't look all that bad by itself, it's still oversimplified.
    A far more complicated sub-select would be needed to
    select the right OID if there are multiple tables named
    <literal>mytable</literal> in different schemas.
    The <type>regclass</type> input converter handles the table lookup according
    to the schema path setting, and so it does the <quote>right thing</quote>
    automatically.  Similarly, casting a table's OID to
    <type>regclass</type> is handy for symbolic display