<term><literal>PGTYPES_TS_BAD_TIMESTAMP</literal></term>
      <listitem>
       <para>
        An invalid timestamp string pass passed to
        the <function>PGTYPEStimestamp_from_asc</function> function,
        or an invalid timestamp value was passed to
        the <function>PGTYPEStimestamp_to_asc</function> function.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="ecpg-pgtypes-errno-pgtypes-ts-err-einftime">
      <term><literal>PGTYPES_TS_ERR_EINFTIME</literal></term>
      <listitem>
       <para>
        An infinite timestamp value was encountered in a context that
        cannot handle it.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>
   </para>
  </sect2>

   <sect2 id="ecpg-pgtypes-constants">
    <title>Special Constants of pgtypeslib</title>
   <para>
    <variablelist>
     <varlistentry id="pgtypesinvalidtimestamp">
      <term><literal>PGTYPESInvalidTimestamp</literal></term>
      <listitem>
       <para>
        A value of type timestamp representing an invalid time stamp. This is
        returned by the function <function>PGTYPEStimestamp_from_asc</function> on
        parse error.
        Note that due to the internal representation of the <type>timestamp</type> data type,
        <literal>PGTYPESInvalidTimestamp</literal> is also a valid timestamp at
        the same time. It is set to <literal>1899-12-31 23:59:59</literal>. In order
        to detect errors, make sure that your application does not only test
        for <literal>PGTYPESInvalidTimestamp</literal> but also for
        <literal>errno != 0</literal> after each call to
        <function>PGTYPEStimestamp_from_asc</function>.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>
   </para>
  </sect2>
 </sect1>

 <sect1 id="ecpg-descriptors">
  <title>Using Descriptor Areas</title>

  <para>
   An SQL descriptor area is a more sophisticated method for processing
   the result of a <command>SELECT</command>, <command>FETCH</command> or
   a <command>DESCRIBE</command> statement. An SQL descriptor area groups
   the data of one row of data together with metadata items into one
   data structure.  The metadata is particularly useful when executing
   dynamic SQL statements, where the nature of the result columns might
   not be known ahead of time. PostgreSQL provides two ways to use
   Descriptor Areas: the named SQL Descriptor Areas and the C-structure
   SQLDAs.
  </para>

  <sect2 id="ecpg-named-descriptors">
   <title>Named SQL Descriptor Areas</title>

   <para>
    A named SQL descriptor area consists of a header, which contains
    information concerning the entire descriptor, and one or more item
    descriptor areas, which basically each describe one column in the
    result row.
   </para>

   <para>
    Before you can use an SQL descriptor area, you need to allocate one:
<programlisting>
EXEC SQL ALLOCATE DESCRIPTOR <replaceable>identifier</replaceable>;
</programlisting>
    The identifier serves as the <quote>variable name</quote> of the
    descriptor area.  <!-- The scope of the allocated descriptor is WHAT?. -->
    When you don't need the descriptor anymore, you should deallocate
    it:
<programlisting>
EXEC SQL DEALLOCATE DESCRIPTOR <replaceable>identifier</replaceable>;
</programlisting>
   </para>

   <para>
    To use a descriptor area, specify it as the storage target in an
    <literal>INTO</literal> clause, instead of listing host variables:
<programlisting>
EXEC SQL FETCH NEXT FROM mycursor INTO SQL DESCRIPTOR mydesc;
</programlisting>
    If the result set is empty, the Descriptor Area will still contain
    the metadata from the query, i.e., the field names.
   </para>

   <para>
    For not yet executed prepared queries, the <command>DESCRIBE</command>
    statement can be used to get the metadata of the result set:
<programlisting>
EXEC SQL BEGIN DECLARE SECTION;
char *sql_stmt = "SELECT * FROM table1";
EXEC SQL END DECLARE SECTION;

EXEC