Improve non-thread-safe mention of libpq's crypt.

diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 3e9fb16..d487cce 100644 (file)
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -1,5 +1,5 @@
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v 1.86 2002/01/18 20:32:54 momjian Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v 1.87 2002/01/18 20:39:04 momjian Exp $
 -->
 
  <chapter id="libpq">
@@ -2114,13 +2114,6 @@ time. In particular, you cannot issue concurrent queries from different
 threads through the same connection object. (If you need to run
 concurrent queries, start up multiple connections.)
 </para>
-<para>
-However, <filename>libpq</filename> clients using the
-<literal>crypt</literal> encryption method rely on the
-<literal>crypt()</literal> operating system function, which often is not
-thread-safe. It is better to use <literal>MD5</literal> encryption,
-which is guarantted to be thread-safe on all platforms.
-</para>
 
 <para>
 <structname>PGresult</> objects are read-only after creation, and so can be passed around
@@ -2135,6 +2128,13 @@ replaced by <function>PQoidValue</function>.  There is no good reason to
 call <function>fe_setauthsvc</function> at all.
 </para>
 
+<para>
+<filename>Libpq</filename> clients using the <literal>crypt</literal>
+encryption method rely on the <literal>crypt()</literal> operating
+system function, which is often not thread-safe. It is better to use
+<literal>MD5</literal> encryption, which is thread-safe on all
+platforms.
+</para>
 </sect1>