recommended</emphasis>, because it will fail for
    tables that are outside your search path or have names that require
    quoting.
   </para>

   <para>
    An additional property of most of the OID alias types is the creation of
    dependencies.  If a
    constant of one of these types appears in a stored expression
    (such as a column default expression or view), it creates a dependency
    on the referenced object.  For example, if a column has a default
    expression <literal>nextval('my_seq'::regclass)</literal>,
    <productname>PostgreSQL</productname>
    understands that the default expression depends on the sequence
    <literal>my_seq</literal>, so the system will not let the sequence
    be dropped without first removing the default expression.  The
    alternative of <literal>nextval('my_seq'::text)</literal> does not
    create a dependency.
    (<type>regrole</type> is an exception to this property. Constants of this
    type are not allowed in stored expressions.)
   </para>

   <para>
    Another identifier type used by the system is <type>xid</type>, or transaction
    (abbreviated <abbrev>xact</abbrev>) identifier.  This is the data type of the system columns
    <structfield>xmin</structfield> and <structfield>xmax</structfield>.  Transaction identifiers are 32-bit quantities.
    In some contexts, a 64-bit variant <type>xid8</type> is used.  Unlike
    <type>xid</type> values, <type>xid8</type> values increase strictly
    monotonically and cannot be reused in the lifetime of a database
    cluster.  See <xref linkend="transaction-id"/> for more details.
   </para>

   <para>
    A third identifier type used by the system is <type>cid</type>, or
    command identifier.  This is the data type of the system columns
    <structfield>cmin</structfield> and <structfield>cmax</structfield>. Command identifiers are also 32-bit quantities.
   </para>

   <para>
    A final identifier type used by the system is <type>tid</type>, or tuple
    identifier (row identifier).  This is the data type of the system column
    <structfield>ctid</structfield>.  A tuple ID is a pair
    (block number, tuple index within block) that identifies the
    physical location of the row within its table.
   </para>

   <para>
    (The system columns are further explained in <xref
    linkend="ddl-system-columns"/>.)
   </para>
  </sect1>

  <sect1 id="datatype-pg-lsn">
   <title><type>pg_lsn</type> Type</title>

   <indexterm zone="datatype-pg-lsn">
    <primary>pg_lsn</primary>
   </indexterm>

   <para>
    The <type>pg_lsn</type> data type can be used to store LSN (Log Sequence
    Number) data which is a pointer to a location in the WAL. This type is a
    representation of <type>XLogRecPtr</type> and an internal system type of
    <productname>PostgreSQL</productname>.
   </para>

   <para>
    Internally, an LSN is a 64-bit integer, representing a byte position in
    the write-ahead log stream.  It is printed as two hexadecimal numbers of
    up to 8 digits each, separated by a slash; for example,
    <literal>16/B374D848</literal>.  The <type>pg_lsn</type> type supports the
    standard comparison operators, like <literal>=</literal> and
    <literal>&gt;</literal>.  Two LSNs can be subtracted using the
    <literal>-</literal> operator; the result is the number of bytes separating
    those write-ahead log locations.  Also the number of bytes can be
    added into and subtracted from LSN using the
    <literal>+(pg_lsn,numeric)</literal> and
    <literal>-(pg_lsn,numeric)</literal> operators, respectively. Note that
    the calculated LSN should be in the range of <type>pg_lsn</type> type,
    i.e., between <literal>0/0</literal> and
    <literal>FFFFFFFF/FFFFFFFF</literal>.
   </para>
  </sect1>

  <sect1 id="datatype-pseudo">
   <title>Pseudo-Types</title>

   <indexterm zone="datatype-pseudo">
    <primary>record</primary>
   </indexterm>

   <indexterm zone="datatype-pseudo">
    <primary>any</primary>
   </indexterm>