Avoid saying "random" when randomness is not actually meant.

Per Thom Brown.

doc/src/sgml/ddl.sgml

-<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.94 2010/07/29 19:34:40 petere Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.95 2010/08/20 13:59:45 tgl Exp $ -->
 
 <chapter id="ddl">
  <title>Data Definition</title>
@@ -36,7 +36,7 @@
    is fixed, and each column has a name.  The number of rows is
    variable &mdash; it reflects how much data is stored at a given moment.
    SQL does not make any guarantees about the order of the rows in a
-   table.  When a table is read, the rows will appear in random order,
+   table.  When a table is read, the rows will appear in an unspecified order,
    unless sorting is explicitly requested.  This is covered in <xref
    linkend="queries">.  Furthermore, SQL does not assign unique
    identifiers to rows, so it is possible to have several completely

doc/src/sgml/textsearch.sgml

-<!-- $PostgreSQL: pgsql/doc/src/sgml/textsearch.sgml,v 1.57 2010/07/29 19:34:40 petere Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/textsearch.sgml,v 1.58 2010/08/20 13:59:45 tgl Exp $ -->
 
 <chapter id="textsearch">
  <title>Full Text Search</title>
@@ -3270,7 +3270,7 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
    (<productname>PostgreSQL</productname> does this automatically when needed.)
    GiST indexes are lossy because each document is represented in the
    index by a fixed-length signature. The signature is generated by hashing
-   each word into a random bit in an n-bit string, with all these bits OR-ed
+   each word into a single bit in an n-bit string, with all these bits OR-ed
    together to produce an n-bit document signature.  When two words hash to
    the same bit position there will be a false match.  If all words in
    the query have matches (real or false) then the table row must be