follow, a new implicit
     transaction block will be started for them.
    </para>

    <para>
     Savepoints are not allowed in an implicit transaction block, since
     they would conflict with the behavior of automatically closing the
     block upon any error.
    </para>

    <para>
     Remember that, regardless of any transaction control commands that may
     be present, execution of the Query message stops at the first error.
     Thus for example given
<programlisting>
BEGIN;
SELECT 1/0;
ROLLBACK;
</programlisting>
     in a single Query message, the session will be left inside a failed
     regular transaction block, since the <command>ROLLBACK</command> is not
     reached after the divide-by-zero error.  Another <command>ROLLBACK</command>
     will be needed to restore the session to a usable state.
    </para>

    <para>
     Another behavior of note is that initial lexical and syntactic
     analysis is done on the entire query string before any of it is
     executed.  Thus simple errors (such as a misspelled keyword) in later
     statements can prevent execution of any of the statements.  This
     is normally invisible to users since the statements would all roll
     back anyway when done as an implicit transaction block.  However,
     it can be visible when attempting to do multiple transactions within a
     multi-statement Query.  For instance, if a typo turned our previous
     example into
<programlisting>
BEGIN;
INSERT INTO mytable VALUES(1);
COMMIT;
INSERT INTO mytable VALUES(2);
SELCT 1/0;<!-- this typo is intentional -->
</programlisting>
     then none of the statements would get run, resulting in the visible
     difference that the first <command>INSERT</command> is not committed.
     Errors detected at semantic analysis or later, such as a misspelled
     table or column name, do not have this effect.
    </para>
   </sect3>
  </sect2>

  <sect2 id="protocol-flow-ext-query">
   <title>Extended Query</title>

   <para>
    The extended query protocol breaks down the above-described simple
    query protocol into multiple steps.  The results of preparatory
    steps can be re-used multiple times for improved efficiency.
    Furthermore, additional features are available, such as the possibility
    of supplying data values as separate parameters instead of having to
    insert them directly into a query string.
   </para>

   <para>
    In the extended protocol, the frontend first sends a Parse message,
    which contains a textual query string, optionally some information
    about data types of parameter placeholders, and the
    name of a destination prepared-statement object (an empty string
    selects the unnamed prepared statement).  The response is
    either ParseComplete or ErrorResponse.  Parameter data types can be
    specified by OID; if not given, the parser attempts to infer the
    data types in the same way as it would do for untyped literal string
    constants.
   </para>

   <note>
    <para>
     A parameter data type can be left unspecified by setting it to zero,
     or by making the array of parameter type OIDs shorter than the
     number of parameter symbols (<literal>$</literal><replaceable>n</replaceable>)
     used in the query string.  Another special case is that a parameter's
     type can be specified as <type>void</type> (that is, the OID of the
     <type>void</type> pseudo-type).  This is meant to allow parameter symbols
     to be used for function parameters that are actually OUT parameters.
     Ordinarily there is no context in which a <type>void</type> parameter
     could be used, but if such a parameter symbol appears in a function's
     parameter list, it is effectively ignored.  For example, a function
     call such as <literal>foo($1,$2,$3,$4)</literal> could match a function with
     two IN and two OUT arguments, if <literal>$3</literal> and <literal>$4</literal>
     are specified as having type <type>void</type>.
    </para>
   </note>