<para>
     A typical application is the use of <literal>WHENEVER NOT FOUND
     BREAK</literal> to handle looping through result sets:
<programlisting>
int
main(void)
{
    EXEC SQL CONNECT TO testdb AS con1;
    EXEC SQL SELECT pg_catalog.set_config('search_path', '', false); EXEC SQL COMMIT;
    EXEC SQL ALLOCATE DESCRIPTOR d;
    EXEC SQL DECLARE cur CURSOR FOR SELECT current_database(), 'hoge', 256;
    EXEC SQL OPEN cur;

    /* when end of result set reached, break out of while loop */
    EXEC SQL WHENEVER NOT FOUND DO BREAK;

    while (1)
    {
        EXEC SQL FETCH NEXT FROM cur INTO SQL DESCRIPTOR d;
        ...
    }

    EXEC SQL CLOSE cur;
    EXEC SQL COMMIT;

    EXEC SQL DEALLOCATE DESCRIPTOR d;
    EXEC SQL DISCONNECT ALL;

    return 0;
}
</programlisting>
    </para>
   </refsect1>

   <refsect1>
    <title>Compatibility</title>

    <para>
     <command>WHENEVER</command> is specified in the SQL standard, but
     most of the actions are PostgreSQL extensions.
    </para>
   </refsect1>
  </refentry>
 </sect1>

 <sect1 id="ecpg-informix-compat">
  <title><productname>Informix</productname> Compatibility Mode</title>
  <para>
   <command>ecpg</command> can be run in a so-called <firstterm>Informix compatibility mode</firstterm>. If
   this mode is active, it tries to behave as if it were the <productname>Informix</productname>
   precompiler for <productname>Informix</productname> E/SQL. Generally spoken this will allow you to use
   the dollar sign instead of the <literal>EXEC SQL</literal> primitive to introduce
   embedded SQL commands:
<programlisting>
$int j = 3;
$CONNECT TO :dbname;
$CREATE TABLE test(i INT PRIMARY KEY, j INT);
$INSERT INTO test(i, j) VALUES (7, :j);
$COMMIT;
</programlisting>
  </para>

  <note>
   <para>
    There must not be any white space between the <literal>$</literal>
    and a following preprocessor directive, that is,
    <literal>include</literal>, <literal>define</literal>, <literal>ifdef</literal>,
    etc.  Otherwise, the preprocessor will parse the token as a host
    variable.
   </para>
  </note>

  <para>
   There are two compatibility modes: <literal>INFORMIX</literal>, <literal>INFORMIX_SE</literal>
  </para>
  <para>
   When linking programs that use this compatibility mode, remember to link
   against <literal>libcompat</literal> that is shipped with ECPG.
  </para>
  <para>
   Besides the previously explained syntactic sugar, the <productname>Informix</productname> compatibility
   mode ports some functions for input, output and transformation of data as
   well as embedded SQL statements known from E/SQL to ECPG.
  </para>
  <para>
   <productname>Informix</productname> compatibility mode is closely connected to the pgtypeslib library
   of ECPG. pgtypeslib maps SQL data types to data types within the C host
   program and most of the additional functions of the <productname>Informix</productname> compatibility
   mode allow you to operate on those C host program types. Note however that
   the extent of the compatibility is limited. It does not try to copy <productname>Informix</productname>
   behavior; it allows you to do more or less the same operations and gives
   you functions that have the same name and the same basic behavior but it is
   no drop-in replacement if you are using <productname>Informix</productname> at the moment. Moreover,
   some of the data types are different. For example,
   <productname>PostgreSQL</productname>'s datetime and interval types do not
   know about ranges like for example <literal>YEAR TO MINUTE</literal> so you won't
   find support in ECPG for that either.
  </para>

  <sect2 id="ecpg-informix-types">
   <title>Additional Types</title>
   <para>
    The Informix-special "string" pseudo-type for storing right-trimmed character string data is now
    supported in Informix-mode without using <literal>typedef</literal>. In fact, in Informix-mode,
    ECPG refuses to process source files that contain <literal>typedef sometype