Update Statement-Based Replication Middleware docs to be more general.

doc/src/sgml/high-availability.sgml

-<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.5 2006/11/21 18:15:45 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.6 2006/11/21 18:31:57 momjian Exp $ -->
 
 <chapter id="high-availability">
  <title>High Availability and Load Balancing</title>
@@ -166,16 +166,16 @@ protocol to make nodes agree on a serializable transactional order.
    </para>
 
    <para>
-    One limitation of this solution is that functions like
+    If queries are simply broadcast unmodified, functions like
     <function>random()</>, <function>CURRENT_TIMESTAMP</>, and
-    sequences can have different values on different servers.  This
-    is because each server operates independently, and because SQL
-    queries are broadcast (and not actual modified rows).  If this
-    is unacceptable, applications must query such values from a
-    single server and then use those values in write queries.
-    Also, care must be taken that all transactions either commit
-    or abort on all servers, perhaps using two-phase commit (<xref
-    linkend="sql-prepare-transaction"
+    sequences would have different values on different servers.
+    This is because each server operates independently, and because
+    SQL queries are broadcast (and not actual modified rows).  If
+    this is unacceptable, either the middleware or the application
+    must query such values from a single server and then use those
+    values in write queries.  Also, care must be taken that all
+    transactions either commit or abort on all servers, perhaps
+    using two-phase commit (<xref linkend="sql-prepare-transaction"
     endterm="sql-prepare-transaction-title"> and <xref
     linkend="sql-commit-prepared" endterm="sql-commit-prepared-title">.
     Pgpool is an example of this type of replication.