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 string;</literal>
<programlisting>
EXEC SQL BEGIN DECLARE SECTION;
string userid; /* this variable will contain trimmed data */
EXEC SQL END DECLARE SECTION;

EXEC SQL FETCH MYCUR INTO :userid;
</programlisting>
   </para>
  </sect2>

  <sect2 id="ecpg-informix-statements">
   <title>Additional/Missing Embedded SQL Statements</title>
   <para>
    <variablelist>
     <varlistentry id="ecpg-informix-statements-close-database">
      <term><literal>CLOSE DATABASE</literal></term>
      <listitem>
       <para>
        This statement closes the current connection. In fact, this is a
        synonym for ECPG's <literal>DISCONNECT CURRENT</literal>:
<programlisting>
$CLOSE DATABASE;                /* close the current connection */
EXEC SQL CLOSE DATABASE;
</programlisting>
       </para>
      </listitem>
     </varlistentry>
     <varlistentry id="ecpg-informix-statements-free-cursor-name">
      <term><literal>FREE cursor_name</literal></term>
      <listitem>
       <para>
        Due to differences in how ECPG works compared to Informix's ESQL/C (namely, which steps
        are purely grammar transformations and which steps rely on the underlying run-time library)
        there is no <literal>FREE cursor_name</literal> statement in ECPG. This is because in ECPG,
        <literal>DECLARE CURSOR</literal> doesn't translate to a function call into
        the run-time library that uses to the cursor name. This means that there's no run-time
        bookkeeping of SQL cursors in the ECPG run-time library, only in the PostgreSQL server.
       </para>
      </listitem>
     </varlistentry>
     <varlistentry id="ecpg-informix-statements-free-statement-name">
      <term><literal>FREE statement_name</literal></term>
      <listitem>
       <para>
        <literal>FREE statement_name</literal> is a synonym for <literal>DEALLOCATE PREPARE statement_name</literal>.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>
   </para>
  </sect2>

  <sect2 id="ecpg-informix-sqlda">
   <title>Informix-compatible SQLDA Descriptor Areas</title>
   <para>
    Informix-compatible mode supports a different structure than the one described in
    <xref linkend="ecpg-sqlda-descriptors"/>. See below:
<programlisting>
struct sqlvar_compat
{
    short   sqltype;
    int     sqllen;
    char   *sqldata;
    short  *sqlind;
    char   *sqlname;
    char   *sqlformat;
    short   sqlitype;
    short   sqlilen;
    char   *sqlidata;
    int     sqlxid;
    char   *sqltypename;
    short   sqltypelen;
    short   sqlownerlen;
    short   sqlsourcetype;
    char   *sqlownername;
    int     sqlsourceid;
    char   *sqlilongdata;
    int     sqlflags;
    void   *sqlreserved;
};

struct sqlda_compat
{
    short  sqld;
    struct sqlvar_compat *sqlvar;
    char   desc_name[19];
    short  desc_occ;
    struct sqlda_compat *desc_next;
    void  *reserved;
};

typedef struct sqlvar_compat    sqlvar_t;
typedef struct sqlda_compat     sqlda_t;
</programlisting>