List:Commits« Previous MessageNext Message »
From:paul Date:January 21 2006 3:45am
Subject:svn commit - mysqldoc@docsrva: r963 - in trunk: . refman-4.1 refman-5.0 refman-5.1
View as plain text  
Author: paul
Date: 2006-01-21 04:45:12 +0100 (Sat, 21 Jan 2006)
New Revision: 963

Log:
 r6511@frost:  paul | 2006-01-20 21:44:57 -0600
 General revisions.


Modified:
   trunk/
   trunk/refman-4.1/connector-odbc.xml
   trunk/refman-4.1/database-administration.xml
   trunk/refman-4.1/functions.xml
   trunk/refman-4.1/innodb.xml
   trunk/refman-5.0/connector-odbc.xml
   trunk/refman-5.0/database-administration.xml
   trunk/refman-5.0/functions.xml
   trunk/refman-5.0/information-schema.xml
   trunk/refman-5.0/innodb.xml
   trunk/refman-5.0/storage-engines.xml
   trunk/refman-5.1/connector-odbc.xml
   trunk/refman-5.1/database-administration.xml
   trunk/refman-5.1/functions.xml
   trunk/refman-5.1/information-schema.xml
   trunk/refman-5.1/innodb.xml
   trunk/refman-5.1/storage-engines.xml


Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6506
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2396
   + b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6511
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2396

Modified: trunk/refman-4.1/connector-odbc.xml
===================================================================
--- trunk/refman-4.1/connector-odbc.xml	2006-01-21 03:10:02 UTC (rev 962)
+++ trunk/refman-4.1/connector-odbc.xml	2006-01-21 03:45:12 UTC (rev 963)
@@ -4141,8 +4141,8 @@
             Tested with BDE 3.0. The only known problem is that when the
             table schema changes, query fields are not updated. BDE,
             however, does not seem to recognize primary keys, only the
-            index named <literal>PRIMARY</literal>, though this has not
-            been a problem.
+            index named <literal>PRIMARY</literal>, although this has
+            not been a problem.
           </para>
         </listitem>
 
@@ -4218,7 +4218,7 @@
             Enterprise 2000 to MySQL via MyODBC (2.50.37 or greater) and
             using Visio's reverse engineer function to retrieve
             information about the DB (Visio shows all the column
-            definitions, primary keys, Indexes and so on). Also we
+            definitions, primary keys, indexes and so on). Also, we
             tested by designing new tables in Visio and exported them to
             MySQL via MyODBC.
           </para>

Modified: trunk/refman-4.1/database-administration.xml
===================================================================
--- trunk/refman-4.1/database-administration.xml	2006-01-21 03:10:02 UTC (rev 962)
+++ trunk/refman-4.1/database-administration.xml	2006-01-21 03:45:12 UTC (rev 963)
@@ -6073,7 +6073,7 @@
               Increasing this value increases the number of file
               descriptors that <command>mysqld</command> requires. See
               <xref linkend="table-cache"/>, for comments on file
-              descriptor limits. Also see
+              descriptor limits. See also
               <xref linkend="too-many-connections"/>.
             </para>
           </listitem>

Modified: trunk/refman-4.1/functions.xml
===================================================================
--- trunk/refman-4.1/functions.xml	2006-01-21 03:10:02 UTC (rev 962)
+++ trunk/refman-4.1/functions.xml	2006-01-21 03:45:12 UTC (rev 963)
@@ -7013,7 +7013,7 @@
         <remark role="help-description-begin"/>
 
         <para>
-          Given a daynumber <replaceable>N</replaceable>, returns a
+          Given a day number <replaceable>N</replaceable>, returns a
           <literal>DATE</literal> value.
         </para>
 
@@ -7838,7 +7838,7 @@
         <remark role="help-description-begin"/>
 
         <para>
-          This is the reverse of the <literal>DATE_FORMAT()</literal>
+          This is the inverse of the <literal>DATE_FORMAT()</literal>
           function. It takes a string <replaceable>str</replaceable> and
           a format string <replaceable>format</replaceable>.
           <literal>STR_TO_DATE()</literal> returns a
@@ -7871,12 +7871,10 @@
           <replaceable>str</replaceable> should be given in the format
           indicated by <replaceable>format</replaceable>. For the
           specifiers that can be used in
-          <replaceable>format</replaceable>, see the table in the
-          <literal>DATE_FORMAT()</literal> function description. All
-          other characters are just taken verbatim, thus not being
-          interpreted. If <replaceable>str</replaceable> contains an
-          illegal date, time, or datetime value,
-          <literal>STR_TO_DATE()</literal> returns
+          <replaceable>format</replaceable>, see the
+          <literal>DATE_FORMAT()</literal> function description. If
+          <replaceable>str</replaceable> contains an illegal date, time,
+          or datetime value, <literal>STR_TO_DATE()</literal> returns
           <literal>NULL</literal>.
         </para>
 
@@ -7971,17 +7969,17 @@
 </programlisting>
 
         <para>
-          <emphasis role="bold">Note</emphasis> that you cannot use
-          format <literal>"%X%V"</literal> to convert a year-week string
-          to a date as the combination of a year and week does not
+          <emphasis role="bold">Note</emphasis>: You cannot use format
+          <literal>"%X%V"</literal> to convert a year-week string to a
+          date because the combination of a year and week does not
           uniquely identify a year and month if the week crosses a month
           boundary. To convert a year-week to a date, then you should
           also specify the weekday:
         </para>
 
 <programlisting>
-mysql&gt; <userinput>select str_to_date('200442 Monday', '%X%V %W');</userinput>
--&gt; 2004-10-18
+mysql&gt; <userinput>SELECT STR_TO_DATE('200442 Monday', '%X%V %W');</userinput>
+        -&gt; '2004-10-18'
 </programlisting>
 
         <remark role="help-description-end"/>
@@ -8178,7 +8176,7 @@
           datetime value. With two arguments, it adds the time
           expression <replaceable>expr2</replaceable> to the date or
           datetime expression <replaceable>expr</replaceable> and
-          returns theresult as a datetime value.
+          returns the result as a datetime value.
         </para>
 
         <remark role="help-description-end"/>
@@ -8217,9 +8215,9 @@
         <para>
           This is used like the <literal>DATE_FORMAT()</literal>
           function, but the <replaceable>format</replaceable> string may
-          contain only those format specifiers that handle hours,
-          minutes, and seconds. Other specifiers produce a
-          <literal>NULL</literal> value or <literal>0</literal>.
+          contain format specifiers only for hours, minutes, and
+          seconds. Other specifiers produce a <literal>NULL</literal>
+          value or <literal>0</literal>.
         </para>
 
         <remark role="help-description-end"/>
@@ -8293,8 +8291,8 @@
         <remark role="help-description-begin"/>
 
         <para>
-          Given a date <replaceable>date</replaceable>, returns a
-          daynumber (the number of days since year 0).
+          Given a date <replaceable>date</replaceable>, returns a day
+          number (the number of days since year 0).
         </para>
 
         <remark role="help-description-end"/>
@@ -8312,8 +8310,10 @@
           <literal>TO_DAYS()</literal> is not intended for use with
           values that precede the advent of the Gregorian calendar
           (1582), because it does not take into account the days that
-          were lost when the calendar was changed. See
-          <xref linkend="mysql-calendar"/>.
+          were lost when the calendar was changed. For dates before 1582
+          (and possibly a later year in other locales), results from
+          this function are not reliable. See
+          <xref linkend="mysql-calendar"/>, for details.
         </para>
 
         <para>
@@ -8328,12 +8328,6 @@
 mysql&gt; <userinput>SELECT TO_DAYS('1997-10-07'), TO_DAYS('97-10-07');</userinput>
         -&gt; 729669, 729669
 </programlisting>
-
-        <para>
-          For dates before 1582 (and possibly a later year in other
-          locales), results from this function are not reliable. See
-          <xref linkend="mysql-calendar"/>, for details.
-        </para>
       </listitem>
 
       <listitem>
@@ -8725,9 +8719,8 @@
         <para>
           If you would prefer the result to be evaluated with respect to
           the year that contains the first day of the week for the given
-          date, you should use <literal>0</literal>,
-          <literal>2</literal>, <literal>5</literal>, or
-          <literal>7</literal> as the optional
+          date, use <literal>0</literal>, <literal>2</literal>,
+          <literal>5</literal>, or <literal>7</literal> as the optional
           <replaceable>mode</replaceable> argument.
         </para>
 
@@ -8802,8 +8795,9 @@
 
         <para>
           Returns the calendar week of the date as a number in the range
-          from <literal>1</literal> to <literal>53</literal>. It is a
-          compatibility function that is equivalent to
+          from <literal>1</literal> to <literal>53</literal>.
+          <literal>WEEKOFYEAR()</literal> is a compatibility function
+          that is equivalent to
           <literal>WEEK(<replaceable>date</replaceable>,3)</literal>.
         </para>
 
@@ -8841,7 +8835,8 @@
 
         <para>
           Returns the year for <replaceable>date</replaceable>, in the
-          range <literal>1000</literal> to <literal>9999</literal>.
+          range <literal>1000</literal> to <literal>9999</literal>, or
+          <literal>0</literal> for the <quote>zero</quote> date.
         </para>
 
         <remark role="help-description-end"/>
@@ -8997,7 +8992,7 @@
       did not occur at the same time in all countries, and that the
       later it happened, the more days were lost. For example, in Great
       Britain, it took place in 1752, when Wednesday September 2 was
-      followed by Thursday September 14; Russia remained on the Julian
+      followed by Thursday September 14. Russia remained on the Julian
       calendar until 1918, losing 13 days in the process, and what is
       popularly referred to as its <quote>October Revolution</quote>
       occurred in November according to the Gregorian calendar.
@@ -9059,15 +9054,15 @@
           and searching. A full-text index in MySQL is an index of type
           <literal>FULLTEXT</literal>. <literal>FULLTEXT</literal>
           indexes can be used only with <literal>MyISAM</literal>
-          tables; they can be created from <literal>CHAR</literal>,
+          tables. They can be created for <literal>CHAR</literal>,
           <literal>VARCHAR</literal>, or <literal>TEXT</literal> columns
-          as part of a <literal>CREATE TABLE</literal> statement or
-          added later using <literal>ALTER TABLE</literal> or
-          <literal>CREATE INDEX</literal>. For large datasets, it is
-          much faster to load your data into a table that has no
-          <literal>FULLTEXT</literal> index, and then create the index
-          afterwards, than to load data into a table that has an
-          existing <literal>FULLTEXT</literal> index.
+          with <literal>CREATE TABLE</literal> or added later using
+          <literal>ALTER TABLE</literal> or <literal>CREATE
+          INDEX</literal>. For large datasets, it is much faster to load
+          your data into a table that has no <literal>FULLTEXT</literal>
+          index and then create the index afterwards, than to load data
+          into a table that has an existing <literal>FULLTEXT</literal>
+          index.
         </para>
 
         <remark role="help-description-end"/>
@@ -9117,14 +9112,14 @@
 
     <para>
       The <literal>MATCH()</literal> function performs a natural
-      language search for a string against a text collection. A
-      collection is a set of one or more columns included in a
-      <literal>FULLTEXT</literal> index. The search string is given as
-      the argument to <literal>AGAINST()</literal>. For each row in the
-      table, <literal>MATCH()</literal> returns a relevance value, that
-      is, a similarity measure between the search string and the text in
-      that row in the columns named in the <literal>MATCH()</literal>
-      list.
+      language search for a string against a <firstterm>text
+      collection</firstterm>. A collection is a set of one or more
+      columns included in a <literal>FULLTEXT</literal> index. The
+      search string is given as the argument to
+      <literal>AGAINST()</literal>. For each row in the table,
+      <literal>MATCH()</literal> returns a relevance value, that is, a
+      similarity measure between the search string and the text in that
+      row in the columns named in the <literal>MATCH()</literal> list.
     </para>
 
     <para>
@@ -9139,13 +9134,13 @@
 
     <para>
       When <literal>MATCH()</literal> is used in a
-      <literal>WHERE</literal> clause, as in the preceding example, the
-      rows returned are automatically sorted with the highest relevance
-      first. Relevance values are non-negative floating-point numbers.
-      Zero relevance means no similarity. Relevance is computed based on
-      the number of words in the row, the number of unique words in that
-      row, the total number of words in the collection, and the number
-      of documents (rows) that contain a particular word.
+      <literal>WHERE</literal> clause, as in the example shown earlier,
+      the rows returned are automatically sorted with the highest
+      relevance first. Relevance values are non-negative floating-point
+      numbers. Zero relevance means no similarity. Relevance is computed
+      based on the number of words in the row, the number of unique
+      words in that row, the total number of words in the collection,
+      and the number of documents (rows) that contain a particular word.
     </para>
 
     <para>
@@ -9159,7 +9154,7 @@
       <literal>article</literal> table's <literal>FULLTEXT</literal>
       index. If you wanted to search the <literal>title</literal> or
       <literal>body</literal> separately, you would need to create
-      <literal>FULLTEXT</literal> indexes for each column.
+      separate <literal>FULLTEXT</literal> indexes for each column.
     </para>
 
     <para>
@@ -9170,13 +9165,13 @@
     </para>
 
     <para>
-      The preceding example is a basic illustration showing how to use
-      the <literal>MATCH()</literal> function where rows are returned in
-      order of decreasing relevance. The next example shows how to
-      retrieve the relevance values explicitly. Returned rows are not
-      ordered because the <literal>SELECT</literal> statement includes
-      neither <literal>WHERE</literal> nor <literal>ORDER BY</literal>
-      clauses:
+      The preceding example is a basic illustration that shows how to
+      use the <literal>MATCH()</literal> function where rows are
+      returned in order of decreasing relevance. The next example shows
+      how to retrieve the relevance values explicitly. Returned rows are
+      not ordered because the <literal>SELECT</literal> statement
+      includes neither <literal>WHERE</literal> nor <literal>ORDER
+      BY</literal> clauses:
     </para>
 
 <programlisting>
@@ -9237,15 +9232,16 @@
 
     <para>
       The <literal>FULLTEXT</literal> parser determines where words
-      start and end by looking for certain delimiters, for example
-      <literal>' '</literal> (the space character), <literal>,</literal>
-      (the comma), and <literal>.</literal> (the period). If words are
-      not separated by delimiters (as in, for example, Chinese), the
+      start and end by looking for certain delimiter characters; for
+      example, &lsquo;<literal>&nbsp;</literal>&rsquo; (space),
+      &lsquo;<literal>,</literal>&rsquo; (comma), and
+      &lsquo;<literal>.</literal>&rsquo; (period). If words are not
+      separated by delimiters (as in, for example, Chinese), the
       <literal>FULLTEXT</literal> parser cannot determine where a word
       begins or ends. To be able to add words or other indexed terms in
       such languages to a <literal>FULLTEXT</literal> index, you must
       preprocess them so that they are separated by some arbitrary
-      delimiter such as <literal>"</literal>.
+      delimiter such as &lsquo;<literal>"</literal>&rsquo;.
     </para>
 
     <para>
@@ -9268,8 +9264,7 @@
           such as <quote>the</quote> or <quote>some</quote> that is so
           common that it is considered to have zero semantic value.
           There is a built-in stopword list, but it can be overwritten
-          by a user-defined list. See
-          <xref linkend="fulltext-fine-tuning"/>.
+          by a user-defined list.
         </para>
       </listitem>
 
@@ -9288,12 +9283,12 @@
 
     <para>
       Every correct word in the collection and in the query is weighted
-      according to its significance in the collection or query. This
-      way, a word that is present in many documents has a lower weight
-      (and may even have a zero weight), because it has lower semantic
-      value in this particular collection. Conversely, if the word is
-      rare, it receives a higher weight. The weights of the words are
-      then combined to compute the relevance of the row.
+      according to its significance in the collection or query.
+      Consequently, a word that is present in many documents has a lower
+      weight (and may even have a zero weight), because it has lower
+      semantic value in this particular collection. Conversely, if the
+      word is rare, it receives a higher weight. The weights of the
+      words are combined to compute the relevance of the row.
     </para>
 
     <para>
@@ -9302,8 +9297,8 @@
       distribution does not adequately reflect their semantic value, and
       this model may sometimes produce bizarre results. For example,
       although the word <quote>MySQL</quote> is present in every row of
-      the <literal>articles</literal> table, a search for the word
-      produces no results:
+      the <literal>articles</literal> table shown earlier, a search for
+      the word produces no results:
     </para>
 
 <programlisting>
@@ -9316,9 +9311,9 @@
       The search result is empty because the word <quote>MySQL</quote>
       is present in at least 50% of the rows. As such, it is effectively
       treated as a stopword. For large datasets, this is the most
-      desirable behavior &mdash; a natural language query should not
-      return every second row from a 1GB table. For small datasets, it
-      may be less desirable.
+      desirable behavior: A natural language query should not return
+      every second row from a 1GB table. For small datasets, it may be
+      less desirable.
     </para>
 
     <para>
@@ -9348,7 +9343,7 @@
       <title>&title-fulltext-boolean;</title>
 
       <para>
-        As of version 4.0.1, MySQL can also perform boolean full-text
+        As of version 4.0.1, MySQL can perform boolean full-text
         searches using the <literal>IN BOOLEAN MODE</literal> modifier:
       </para>
 
@@ -9367,9 +9362,12 @@
 </programlisting>
 
       <para>
-        This query retrieves all the rows that contain the word
-        <quote>MySQL</quote> but that do <emphasis>not</emphasis>
-        contain the word <quote>YourSQL</quote>.
+        The <literal>+</literal> and <literal>-</literal> operators
+        indicate that a word is required to be present or absent,
+        respectively, for a match to occur. Thus, this query retrieves
+        all the rows that contain the word <quote>MySQL</quote> but that
+        do <emphasis>not</emphasis> contain the word
+        <quote>YourSQL</quote>.
       </para>
 
       <para>
@@ -9468,7 +9466,7 @@
 
         <listitem>
           <para>
-            <literal>(no operator)</literal>
+            (no operator)
           </para>
 
           <para>
@@ -9490,7 +9488,7 @@
             to the relevance value that is assigned to a row. The
             <literal>&gt;</literal> operator increases the contribution
             and the <literal>&lt;</literal> operator decreases it. See
-            the example below.
+            the example following this list.
           </para>
         </listitem>
 
@@ -9500,8 +9498,8 @@
           </para>
 
           <para>
-            Parentheses are used to group words into subexpressions.
-            Parenthesized groups can be nested.
+            Parentheses group words into subexpressions. Parenthesized
+            groups can be nested.
           </para>
         </listitem>
 
@@ -9526,9 +9524,11 @@
           </para>
 
           <para>
-            The asterisk serves as the truncation operator. Unlike the
-            other operators, it should be <emphasis>appended</emphasis>
-            to the word to be affected.
+            The asterisk serves as the truncation (or wildcard)
+            operator. Unlike the other operators, it should be
+            <emphasis>appended</emphasis> to the word to be affected.
+            Words match if they begin with the word preceding the
+            <literal>*</literal> operator.
           </para>
         </listitem>
 
@@ -9662,9 +9662,9 @@
             words</quote> (for example, rows that contain <quote>some
             words of wisdom</quote> but not <quote>some noise
             words</quote>). Note that the
-            &lsquo;<literal>"</literal>&rsquo; characters that surround
+            &lsquo;<literal>"</literal>&rsquo; characters that enclose
             the phrase are operator characters that delimit the phrase.
-            They are not the quotes that surround the search string
+            They are not the quotes that enclose the search string
             itself.
           </para>
         </listitem>
@@ -9682,8 +9682,8 @@
         particular, its variant <quote>blind query expansion</quote>).
         This is generally useful when a search phrase is too short,
         which often means that the user is relying on implied knowledge
-        that the full-text search engine usually lacks. For example, a
-        user searching for <quote>database</quote> may really mean that
+        that the full-text search engine lacks. For example, a user
+        searching for <quote>database</quote> may really mean that
         <quote>MySQL</quote>, <quote>Oracle</quote>, <quote>DB2</quote>,
         and <quote>RDBMS</quote> all are phrases that should match
         <quote>databases</quote> and should be returned, too. This is
@@ -9696,12 +9696,13 @@
         EXPANSION</literal> following the search phrase. It works by
         performing the search twice, where the search phrase for the
         second search is the original search phrase concatenated with
-        the few top found documents from the first search. Thus, if one
-        of these documents contains the word <quote>databases</quote>
-        and the word <quote>MySQL</quote>, the second search finds the
-        documents that contain the word <quote>MySQL</quote> even if
-        they do not contain the word <quote>database</quote>. The
-        following example shows this difference:
+        the few most highly relevant documents from the first search.
+        Thus, if one of these documents contains the word
+        <quote>databases</quote> and the word <quote>MySQL</quote>, the
+        second search finds the documents that contain the word
+        <quote>MySQL</quote> even if they do not contain the word
+        <quote>database</quote>. The following example shows this
+        difference:
       </para>
 
 <programlisting>
@@ -10550,7 +10551,7 @@
           <para>
             As of MySQL 4.1.1, full-text searches can be used with most
             multi-byte character sets. The exception is that for
-            Unicode; the <literal>utf8</literal> character set can be
+            Unicode, the <literal>utf8</literal> character set can be
             used, but not the <literal>ucs2</literal> character set.
           </para>
         </listitem>
@@ -10582,7 +10583,8 @@
             exactly the column list in some <literal>FULLTEXT</literal>
             index definition for the table, unless this
             <literal>MATCH()</literal> is <literal>IN BOOLEAN
-            MODE</literal>.
+            MODE</literal>. Boolean-mode searches can be done on
+            non-indexed columns, although they are likely to be slow.
           </para>
         </listitem>
 
@@ -10612,14 +10614,14 @@
       <para>
         Note that full-text search is carefully tuned for the most
         effectiveness. Modifying the default behavior in most cases can
-        actually decrease it. <emphasis>Do not alter the MySQL sources
-        unless you know what you are doing</emphasis>.
+        actually decrease effectiveness. <emphasis>Do not alter the
+        MySQL sources unless you know what you are doing</emphasis>.
       </para>
 
       <para>
-        Most full-text variables described below must be set at server
-        startup time. A server restart is required to change them; they
-        cannot be modified while the server is running.
+        Most full-text variables described in this section must be set
+        at server startup time. A server restart is required to change
+        them; they cannot be modified while the server is running.
       </para>
 
       <para>
@@ -10632,18 +10634,17 @@
 
         <listitem>
           <para>
-            The minimum and maximum length of words to be indexed is
+            The minimum and maximum lengths of words to be indexed are
             defined by the <literal>ft_min_word_len</literal> and
             <literal>ft_max_word_len</literal> system variables
             (available as of MySQL 4.0.0). See
             <xref linkend="server-system-variables"/>.) The default
-            minimum value is four characters; the default maximum
-            depends on the MySQL version in use. If you change either
-            value, you must rebuild your <literal>FULLTEXT</literal>
-            indexes. For example, if you want three-character words to
-            be searchable, you can set the
-            <literal>ft_min_word_len</literal> variable by putting the
-            following lines in an option file:
+            minimum value is four characters; the default maximum is
+            version dependent. If you change either value, you must
+            rebuild your <literal>FULLTEXT</literal> indexes. For
+            example, if you want three-character words to be searchable,
+            you can set the <literal>ft_min_word_len</literal> variable
+            by putting the following lines in an option file:
           </para>
 
 <programlisting>
@@ -10652,9 +10653,9 @@
 </programlisting>
 
           <para>
-            Then restart the server and rebuild your
-            <literal>FULLTEXT</literal> indexes. Also note particularly
-            the remarks regarding <command>myisamchk</command> in the
+            Then you must restart the server and rebuild your
+            <literal>FULLTEXT</literal> indexes. Note particularly the
+            remarks regarding <command>myisamchk</command> in the
             instructions following this list.
           </para>
         </listitem>
@@ -10678,8 +10679,8 @@
             value should be the pathname of the file containing the
             stopword list, or the empty string to disable stopword
             filtering. After changing the value of this variable or the
-            contents of the stopword file, rebuild your
-            <literal>FULLTEXT</literal> indexes.
+            contents of the stopword file, restart the server and
+            rebuild your <literal>FULLTEXT</literal> indexes.
           </para>
 
           <para>
@@ -10716,12 +10717,12 @@
           <para>
             Then recompile MySQL. There is no need to rebuild the
             indexes in this case. <emphasis role="bold">Note</emphasis>:
-            By doing this you <emphasis>severely</emphasis> decrease
-            MySQL's ability to provide adequate relevance values for the
-            <literal>MATCH()</literal> function. If you really need to
-            search for such common words, it would be better to search
-            using <literal>IN BOOLEAN MODE</literal> instead, which does
-            not observe the 50% threshold.
+            By making this change, you <emphasis>severely</emphasis>
+            decrease MySQL's ability to provide adequate relevance
+            values for the <literal>MATCH()</literal> function. If you
+            really need to search for such common words, it would be
+            better to search using <literal>IN BOOLEAN MODE</literal>
+            instead, which does not observe the 50% threshold.
           </para>
         </listitem>
 
@@ -10729,8 +10730,8 @@
           <para>
             To change the operators used for boolean full-text searches,
             set the <literal>ft_boolean_syntax</literal> system variable
-            (available as of MySQL 4.0.1). The variable also can be
-            changed while the server is running, but you must have the
+            (available as of MySQL 4.0.1). The variable can be changed
+            while the server is running, but you must have the
             <literal>SUPER</literal> privilege to do so. No rebuilding
             of indexes is necessary in this case. See
             <xref linkend="server-system-variables"/>, which describes
@@ -10780,17 +10781,18 @@
         Note that if you use <command>myisamchk</command> to perform an
         operation that modifies table indexes (such as repair or
         analyze), the <literal>FULLTEXT</literal> indexes are rebuilt
-        using the default full-text parameter values for minimum and
-        maximum word length and the stopword file unless you specify
-        otherwise. This can result in queries failing.
+        using the <emphasis>default</emphasis> full-text parameter
+        values for minimum word length, maximum word length, and
+        stopword file unless you specify otherwise. This can result in
+        queries failing.
       </para>
 
       <para>
         The problem occurs because these parameters are known only by
         the server. They are not stored in <literal>MyISAM</literal>
         index files. To avoid the problem if you have modified the
-        minimum or maximum word length or the stopword file in the
-        server, specify the same <literal>ft_min_word_len</literal>,
+        minimum or maximum word length or stopword file values used by
+        the server, specify the same <literal>ft_min_word_len</literal>,
         <literal>ft_max_word_len</literal>, and
         <literal>ft_stopword_file</literal> values to
         <command>myisamchk</command> that you use for
@@ -10805,8 +10807,8 @@
 
       <para>
         To ensure that <command>myisamchk</command> and the server use
-        the same values for full-text parameters, you can place each one
-        in both the <literal>[mysqld]</literal> and
+        the same values for full-text parameters, place each one in both
+        the <literal>[mysqld]</literal> and
         <literal>[myisamchk]</literal> sections of an option file:
       </para>
 
@@ -10822,9 +10824,9 @@
         An alternative to using <command>myisamchk</command> is to use
         the <literal>REPAIR TABLE</literal>, <literal>ANALYZE
         TABLE</literal>, <literal>OPTIMIZE TABLE</literal>, or
-        <literal>ALTER TABLE</literal>. These statements are performed
-        by the server, which knows the proper full-text parameter values
-        to use.
+        <literal>ALTER TABLE</literal> statements. These statements are
+        performed by the server, which knows the proper full-text
+        parameter values to use.
       </para>
 
     </section>

Modified: trunk/refman-4.1/innodb.xml
===================================================================
--- trunk/refman-4.1/innodb.xml	2006-01-21 03:10:02 UTC (rev 962)
+++ trunk/refman-4.1/innodb.xml	2006-01-21 03:45:12 UTC (rev 963)
@@ -1275,9 +1275,9 @@
           work regardless of the value. Note that many operating systems
           and some disk hardware fool the flush-to-disk operation. They
           may tell <command>mysqld</command> that the flush has taken
-          place, though it has not. Then the durability of transactions
-          is not guaranteed even with the setting 1, and in the worst
-          case a power outage can even corrupt the
+          place, even though it has not. Then the durability of
+          transactions is not guaranteed even with the setting 1, and in
+          the worst case a power outage can even corrupt the
           <literal>InnoDB</literal> database. Using a battery-backed
           disk cache in the SCSI disk controller or in the disk itself
           speeds up file flushes, and makes the operation safer. You can

Modified: trunk/refman-5.0/connector-odbc.xml
===================================================================
--- trunk/refman-5.0/connector-odbc.xml	2006-01-21 03:10:02 UTC (rev 962)
+++ trunk/refman-5.0/connector-odbc.xml	2006-01-21 03:45:12 UTC (rev 963)
@@ -2098,12 +2098,12 @@
       <title>&title-data-source-name;</title>
 
       <para>
-        A <firstterm>data source</firstterm> is a place where data comes from. The data
-        source must have a persistent identifier, the Data Source Name.
-        Using the Data Source Name, MySQL can access initialization
-        information. With the initialization information, MySQL knows
-        where to access the database and what settings to use when the
-        access starts.
+        A <firstterm>data source</firstterm> is a place where data comes
+        from. The data source must have a persistent identifier, the
+        Data Source Name. Using the Data Source Name, MySQL can access
+        initialization information. With the initialization information,
+        MySQL knows where to access the database and what settings to
+        use when the access starts.
       </para>
 
       <para>
@@ -2126,13 +2126,15 @@
 
       <para>
         If the information is in the Windows registry, it is called a
-        <firstterm>Machine data source</firstterm>. It might be a <firstterm>User data source</firstterm>, in
-        which case only one user can see it. Or it might be a <firstterm>System
-        data source</firstterm> in which case it is accessible to all users on the
-        computer, or indeed to all users connected to the computer, if
-        the users are connected by Microsoft Windows NT services. When
-        you run the ODBC Data Administration program, you have a choice
-        whether to use "User" or "System" -- there are separate tabs.
+        <firstterm>Machine data source</firstterm>. It might be a
+        <firstterm>User data source</firstterm>, in which case only one
+        user can see it. Or it might be a <firstterm>System data
+        source</firstterm> in which case it is accessible to all users
+        on the computer, or indeed to all users connected to the
+        computer, if the users are connected by Microsoft Windows NT
+        services. When you run the ODBC Data Administration program, you
+        have a choice whether to use "User" or "System" -- there are
+        separate tabs.
       </para>
 
       <para>
@@ -4139,8 +4141,8 @@
             Tested with BDE 3.0. The only known problem is that when the
             table schema changes, query fields are not updated. BDE,
             however, does not seem to recognize primary keys, only the
-            index named <literal>PRIMARY</literal>, though this has not
-            been a problem.
+            index named <literal>PRIMARY</literal>, although this has
+            not been a problem.
           </para>
         </listitem>
 
@@ -4216,7 +4218,7 @@
             Enterprise 2000 to MySQL via MyODBC (2.50.37 or greater) and
             using Visio's reverse engineer function to retrieve
             information about the DB (Visio shows all the column
-            definitions, primary keys, Indexes and so on). Also we
+            definitions, primary keys, indexes and so on). Also, we
             tested by designing new tables in Visio and exported them to
             MySQL via MyODBC.
           </para>

Modified: trunk/refman-5.0/database-administration.xml
===================================================================
--- trunk/refman-5.0/database-administration.xml	2006-01-21 03:10:02 UTC (rev 962)
+++ trunk/refman-5.0/database-administration.xml	2006-01-21 03:45:12 UTC (rev 963)
@@ -7547,7 +7547,7 @@
               Increasing this value increases the number of file
               descriptors that <command>mysqld</command> requires. See
               <xref linkend="table-cache"/>, for comments on file
-              descriptor limits. Also see
+              descriptor limits. See also
               <xref linkend="too-many-connections"/>.
             </para>
           </listitem>
@@ -23350,8 +23350,8 @@
             server is started with
             <literal>binlog-do-db=sales</literal>, and you do
             <literal>USE prices; UPDATE sales.january SET
-            amount=amount+1000;</literal>, this statement
-            is <emphasis>not</emphasis> written into the binary log.
+            amount=amount+1000;</literal>, this statement is
+            <emphasis>not</emphasis> written into the binary log.
           </para>
         </listitem>
 
@@ -23373,8 +23373,8 @@
             server is started with
             <literal>binlog-ignore-db=sales</literal>, and you do
             <literal>USE prices; UPDATE sales.january SET
-            amount=amount+1000;</literal>, this statement <emphasis>is</emphasis> written
-            into the binary log.
+            amount=amount+1000;</literal>, this statement
+            <emphasis>is</emphasis> written into the binary log.
           </para>
 
           <para>

Modified: trunk/refman-5.0/functions.xml
===================================================================
--- trunk/refman-5.0/functions.xml	2006-01-21 03:10:02 UTC (rev 962)
+++ trunk/refman-5.0/functions.xml	2006-01-21 03:45:12 UTC (rev 963)
@@ -7088,7 +7088,7 @@
         <remark role="help-description-begin"/>
 
         <para>
-          Given a daynumber <replaceable>N</replaceable>, returns a
+          Given a day number <replaceable>N</replaceable>, returns a
           <literal>DATE</literal> value.
         </para>
 
@@ -7696,7 +7696,8 @@
           Within a stored routine or trigger, <literal>NOW()</literal>
           returns a constant time that indicates the time at which the
           routine or triggering statement began to execute. This differs
-          from the behavior for <literal>SYSDATE()</literal>.
+          from the behavior for <literal>SYSDATE()</literal>, which
+          returns the exact time at which it executes.
         </para>
       </listitem>
 
@@ -7894,7 +7895,7 @@
         <remark role="help-description-begin"/>
 
         <para>
-          This is the reverse of the <literal>DATE_FORMAT()</literal>
+          This is the inverse of the <literal>DATE_FORMAT()</literal>
           function. It takes a string <replaceable>str</replaceable> and
           a format string <replaceable>format</replaceable>.
           <literal>STR_TO_DATE()</literal> returns a
@@ -7927,12 +7928,10 @@
           <replaceable>str</replaceable> should be given in the format
           indicated by <replaceable>format</replaceable>. For the
           specifiers that can be used in
-          <replaceable>format</replaceable>, see the table in the
-          <literal>DATE_FORMAT()</literal> function description. All
-          other characters are just taken verbatim, thus not being
-          interpreted. If <replaceable>str</replaceable> contains an
-          illegal date, time, or datetime value,
-          <literal>STR_TO_DATE()</literal> returns
+          <replaceable>format</replaceable>, see the
+          <literal>DATE_FORMAT()</literal> function description. If
+          <replaceable>str</replaceable> contains an illegal date, time,
+          or datetime value, <literal>STR_TO_DATE()</literal> returns
           <literal>NULL</literal>. Starting from MySQL 5.0.3, an illegal
           value also produces a warning.
         </para>
@@ -8010,9 +8009,9 @@
 
         <para>
           The second form allows the use of an integer value for
-          <replaceable>days</replaceable>. In such cases, it is reckoned
-          to be the number of days to be subtracted from the date or
-          datetime expression <replaceable>expr</replaceable>.
+          <replaceable>days</replaceable>. In such cases, it is
+          interpreted as the number of days to be subtracted from the
+          date or datetime expression <replaceable>expr</replaceable>.
         </para>
 
 <programlisting>
@@ -8021,17 +8020,17 @@
 </programlisting>
 
         <para>
-          <emphasis role="bold">Note</emphasis> that you cannot use
-          format <literal>"%X%V"</literal> to convert a year-week string
-          to a date as the combination of a year and week does not
+          <emphasis role="bold">Note</emphasis>: You cannot use format
+          <literal>"%X%V"</literal> to convert a year-week string to a
+          date because the combination of a year and week does not
           uniquely identify a year and month if the week crosses a month
           boundary. To convert a year-week to a date, then you should
           also specify the weekday:
         </para>
 
 <programlisting>
-mysql&gt; <userinput>select str_to_date('200442 Monday', '%X%V %W');</userinput>
--&gt; 2004-10-18
+mysql&gt; <userinput>SELECT STR_TO_DATE('200442 Monday', '%X%V %W');</userinput>
+        -&gt; '2004-10-18'
 </programlisting>
 
         <remark role="help-description-end"/>
@@ -8106,9 +8105,9 @@
         <para>
           Within a stored routine or trigger,
           <literal>SYSDATE()</literal> returns the time at which it
-          executes, not the time at which the routine or triggering
-          statement began to execute. This differs from the behavior for
-          <literal>NOW()</literal>.
+          executes. This differs from the behavior for
+          <literal>NOW()</literal>, which returns the the time at which
+          the routine or triggering statement began to execute.
         </para>
 
         <remark role="help-description-end"/>
@@ -8224,7 +8223,7 @@
           datetime value. With two arguments, it adds the time
           expression <replaceable>expr2</replaceable> to the date or
           datetime expression <replaceable>expr</replaceable> and
-          returns theresult as a datetime value.
+          returns the result as a datetime value.
         </para>
 
         <remark role="help-description-end"/>
@@ -8273,7 +8272,7 @@
           The <replaceable>interval</replaceable> value may be specified
           using one of keywords as shown, or with a prefix of
           <literal>SQL_TSI_</literal>. For example,
-          <literal>DAY</literal> or <literal>SQL_TSI_DAY</literal> both
+          <literal>DAY</literal> and <literal>SQL_TSI_DAY</literal> both
           are legal.
         </para>
 
@@ -8359,9 +8358,9 @@
         <para>
           This is used like the <literal>DATE_FORMAT()</literal>
           function, but the <replaceable>format</replaceable> string may
-          contain only those format specifiers that handle hours,
-          minutes, and seconds. Other specifiers produce a
-          <literal>NULL</literal> value or <literal>0</literal>.
+          contain format specifiers only for hours, minutes, and
+          seconds. Other specifiers produce a <literal>NULL</literal>
+          value or <literal>0</literal>.
         </para>
 
         <remark role="help-description-end"/>
@@ -8435,8 +8434,8 @@
         <remark role="help-description-begin"/>
 
         <para>
-          Given a date <replaceable>date</replaceable>, returns a
-          daynumber (the number of days since year 0).
+          Given a date <replaceable>date</replaceable>, returns a day
+          number (the number of days since year 0).
         </para>
 
         <remark role="help-description-end"/>
@@ -8454,8 +8453,10 @@
           <literal>TO_DAYS()</literal> is not intended for use with
           values that precede the advent of the Gregorian calendar
           (1582), because it does not take into account the days that
-          were lost when the calendar was changed. See
-          <xref linkend="mysql-calendar"/>.
+          were lost when the calendar was changed. For dates before 1582
+          (and possibly a later year in other locales), results from
+          this function are not reliable. See
+          <xref linkend="mysql-calendar"/>, for details.
         </para>
 
         <para>
@@ -8470,12 +8471,6 @@
 mysql&gt; <userinput>SELECT TO_DAYS('1997-10-07'), TO_DAYS('97-10-07');</userinput>
         -&gt; 729669, 729669
 </programlisting>
-
-        <para>
-          For dates before 1582 (and possibly a later year in other
-          locales), results from this function are not reliable. See
-          <xref linkend="mysql-calendar"/>, for details.
-        </para>
       </listitem>
 
       <listitem>
@@ -8832,9 +8827,8 @@
         <para>
           If you would prefer the result to be evaluated with respect to
           the year that contains the first day of the week for the given
-          date, you should use <literal>0</literal>,
-          <literal>2</literal>, <literal>5</literal>, or
-          <literal>7</literal> as the optional
+          date, use <literal>0</literal>, <literal>2</literal>,
+          <literal>5</literal>, or <literal>7</literal> as the optional
           <replaceable>mode</replaceable> argument.
         </para>
 
@@ -8909,8 +8903,9 @@
 
         <para>
           Returns the calendar week of the date as a number in the range
-          from <literal>1</literal> to <literal>53</literal>. It is a
-          compatibility function that is equivalent to
+          from <literal>1</literal> to <literal>53</literal>.
+          <literal>WEEKOFYEAR()</literal> is a compatibility function
+          that is equivalent to
           <literal>WEEK(<replaceable>date</replaceable>,3)</literal>.
         </para>
 
@@ -8943,7 +8938,8 @@
 
         <para>
           Returns the year for <replaceable>date</replaceable>, in the
-          range <literal>1000</literal> to <literal>9999</literal>.
+          range <literal>1000</literal> to <literal>9999</literal>, or
+          <literal>0</literal> for the <quote>zero</quote> date.
         </para>
 
         <remark role="help-description-end"/>
@@ -9095,7 +9091,7 @@
       did not occur at the same time in all countries, and that the
       later it happened, the more days were lost. For example, in Great
       Britain, it took place in 1752, when Wednesday September 2 was
-      followed by Thursday September 14; Russia remained on the Julian
+      followed by Thursday September 14. Russia remained on the Julian
       calendar until 1918, losing 13 days in the process, and what is
       popularly referred to as its <quote>October Revolution</quote>
       occurred in November according to the Gregorian calendar.
@@ -9157,15 +9153,15 @@
           full-text index in MySQL is an index of type
           <literal>FULLTEXT</literal>. <literal>FULLTEXT</literal>
           indexes can be used only with <literal>MyISAM</literal>
-          tables; they can be created from <literal>CHAR</literal>,
+          tables. They can be created for <literal>CHAR</literal>,
           <literal>VARCHAR</literal>, or <literal>TEXT</literal> columns
-          as part of a <literal>CREATE TABLE</literal> statement or
-          added later using <literal>ALTER TABLE</literal> or
-          <literal>CREATE INDEX</literal>. For large datasets, it is
-          much faster to load your data into a table that has no
-          <literal>FULLTEXT</literal> index, and then create the index
-          afterwards, than to load data into a table that has an
-          existing <literal>FULLTEXT</literal> index.
+          with <literal>CREATE TABLE</literal> or added later using
+          <literal>ALTER TABLE</literal> or <literal>CREATE
+          INDEX</literal>. For large datasets, it is much faster to load
+          your data into a table that has no <literal>FULLTEXT</literal>
+          index and then create the index afterwards, than to load data
+          into a table that has an existing <literal>FULLTEXT</literal>
+          index.
         </para>
 
         <remark role="help-description-end"/>
@@ -9215,14 +9211,14 @@
 
     <para>
       The <literal>MATCH()</literal> function performs a natural
-      language search for a string against a text collection. A
-      collection is a set of one or more columns included in a
-      <literal>FULLTEXT</literal> index. The search string is given as
-      the argument to <literal>AGAINST()</literal>. For each row in the
-      table, <literal>MATCH()</literal> returns a relevance value, that
-      is, a similarity measure between the search string and the text in
-      that row in the columns named in the <literal>MATCH()</literal>
-      list.
+      language search for a string against a <firstterm>text
+      collection</firstterm>. A collection is a set of one or more
+      columns included in a <literal>FULLTEXT</literal> index. The
+      search string is given as the argument to
+      <literal>AGAINST()</literal>. For each row in the table,
+      <literal>MATCH()</literal> returns a relevance value, that is, a
+      similarity measure between the search string and the text in that
+      row in the columns named in the <literal>MATCH()</literal> list.
     </para>
 
     <para>
@@ -9236,13 +9232,13 @@
 
     <para>
       When <literal>MATCH()</literal> is used in a
-      <literal>WHERE</literal> clause, as in the preceding example, the
-      rows returned are automatically sorted with the highest relevance
-      first. Relevance values are non-negative floating-point numbers.
-      Zero relevance means no similarity. Relevance is computed based on
-      the number of words in the row, the number of unique words in that
-      row, the total number of words in the collection, and the number
-      of documents (rows) that contain a particular word.
+      <literal>WHERE</literal> clause, as in the example shown earlier,
+      the rows returned are automatically sorted with the highest
+      relevance first. Relevance values are non-negative floating-point
+      numbers. Zero relevance means no similarity. Relevance is computed
+      based on the number of words in the row, the number of unique
+      words in that row, the total number of words in the collection,
+      and the number of documents (rows) that contain a particular word.
     </para>
 
     <para>
@@ -9256,7 +9252,7 @@
       <literal>article</literal> table's <literal>FULLTEXT</literal>
       index. If you wanted to search the <literal>title</literal> or
       <literal>body</literal> separately, you would need to create
-      <literal>FULLTEXT</literal> indexes for each column.
+      separate <literal>FULLTEXT</literal> indexes for each column.
     </para>
 
     <para>
@@ -9267,13 +9263,13 @@
     </para>
 
     <para>
-      The preceding example is a basic illustration showing how to use
-      the <literal>MATCH()</literal> function where rows are returned in
-      order of decreasing relevance. The next example shows how to
-      retrieve the relevance values explicitly. Returned rows are not
-      ordered because the <literal>SELECT</literal> statement includes
-      neither <literal>WHERE</literal> nor <literal>ORDER BY</literal>
-      clauses:
+      The preceding example is a basic illustration that shows how to
+      use the <literal>MATCH()</literal> function where rows are
+      returned in order of decreasing relevance. The next example shows
+      how to retrieve the relevance values explicitly. Returned rows are
+      not ordered because the <literal>SELECT</literal> statement
+      includes neither <literal>WHERE</literal> nor <literal>ORDER
+      BY</literal> clauses:
     </para>
 
 <programlisting>
@@ -9334,15 +9330,16 @@
 
     <para>
       The <literal>FULLTEXT</literal> parser determines where words
-      start and end by looking for certain delimiters, for example
-      <literal>' '</literal> (the space character), <literal>,</literal>
-      (the comma), and <literal>.</literal> (the period). If words are
-      not separated by delimiters (as in, for example, Chinese), the
+      start and end by looking for certain delimiter characters; for
+      example, &lsquo;<literal>&nbsp;</literal>&rsquo; (space),
+      &lsquo;<literal>,</literal>&rsquo; (comma), and
+      &lsquo;<literal>.</literal>&rsquo; (period). If words are not
+      separated by delimiters (as in, for example, Chinese), the
       <literal>FULLTEXT</literal> parser cannot determine where a word
       begins or ends. To be able to add words or other indexed terms in
       such languages to a <literal>FULLTEXT</literal> index, you must
       preprocess them so that they are separated by some arbitrary
-      delimiter such as <literal>"</literal>.
+      delimiter such as &lsquo;<literal>"</literal>&rsquo;.
     </para>
 
     <para>
@@ -9365,8 +9362,7 @@
           such as <quote>the</quote> or <quote>some</quote> that is so
           common that it is considered to have zero semantic value.
           There is a built-in stopword list, but it can be overwritten
-          by a user-defined list. See
-          <xref linkend="fulltext-fine-tuning"/>.
+          by a user-defined list.
         </para>
       </listitem>
 
@@ -9385,12 +9381,12 @@
 
     <para>
       Every correct word in the collection and in the query is weighted
-      according to its significance in the collection or query. This
-      way, a word that is present in many documents has a lower weight
-      (and may even have a zero weight), because it has lower semantic
-      value in this particular collection. Conversely, if the word is
-      rare, it receives a higher weight. The weights of the words are
-      then combined to compute the relevance of the row.
+      according to its significance in the collection or query.
+      Consequently, a word that is present in many documents has a lower
+      weight (and may even have a zero weight), because it has lower
+      semantic value in this particular collection. Conversely, if the
+      word is rare, it receives a higher weight. The weights of the
+      words are combined to compute the relevance of the row.
     </para>
 
     <para>
@@ -9399,8 +9395,8 @@
       distribution does not adequately reflect their semantic value, and
       this model may sometimes produce bizarre results. For example,
       although the word <quote>MySQL</quote> is present in every row of
-      the <literal>articles</literal> table, a search for the word
-      produces no results:
+      the <literal>articles</literal> table shown earlier, a search for
+      the word produces no results:
     </para>
 
 <programlisting>
@@ -9413,9 +9409,9 @@
       The search result is empty because the word <quote>MySQL</quote>
       is present in at least 50% of the rows. As such, it is effectively
       treated as a stopword. For large datasets, this is the most
-      desirable behavior &mdash; a natural language query should not
-      return every second row from a 1GB table. For small datasets, it
-      may be less desirable.
+      desirable behavior: A natural language query should not return
+      every second row from a 1GB table. For small datasets, it may be
+      less desirable.
     </para>
 
     <para>
@@ -9445,7 +9441,7 @@
       <title>&title-fulltext-boolean;</title>
 
       <para>
-        MySQL can also perform boolean full-text searches using the
+        MySQL can perform boolean full-text searches using the
         <literal>IN BOOLEAN MODE</literal> modifier:
       </para>
 
@@ -9464,9 +9460,12 @@
 </programlisting>
 
       <para>
-        This query retrieves all the rows that contain the word
-        <quote>MySQL</quote> but that do <emphasis>not</emphasis>
-        contain the word <quote>YourSQL</quote>.
+        The <literal>+</literal> and <literal>-</literal> operators
+        indicate that a word is required to be present or absent,
+        respectively, for a match to occur. Thus, this query retrieves
+        all the rows that contain the word <quote>MySQL</quote> but that
+        do <emphasis>not</emphasis> contain the word
+        <quote>YourSQL</quote>.
       </para>
 
       <para>
@@ -9565,7 +9564,7 @@
 
         <listitem>
           <para>
-            <literal>(no operator)</literal>
+            (no operator)
           </para>
 
           <para>
@@ -9587,7 +9586,7 @@
             to the relevance value that is assigned to a row. The
             <literal>&gt;</literal> operator increases the contribution
             and the <literal>&lt;</literal> operator decreases it. See
-            the example below.
+            the example following this list.
           </para>
         </listitem>
 
@@ -9597,8 +9596,8 @@
           </para>
 
           <para>
-            Parentheses are used to group words into subexpressions.
-            Parenthesized groups can be nested.
+            Parentheses group words into subexpressions. Parenthesized
+            groups can be nested.
           </para>
         </listitem>
 
@@ -9623,9 +9622,11 @@
           </para>
 
           <para>
-            The asterisk serves as the truncation operator. Unlike the
-            other operators, it should be <emphasis>appended</emphasis>
-            to the word to be affected.
+            The asterisk serves as the truncation (or wildcard)
+            operator. Unlike the other operators, it should be
+            <emphasis>appended</emphasis> to the word to be affected.
+            Words match if they begin with the word preceding the
+            <literal>*</literal> operator.
           </para>
         </listitem>
 
@@ -9763,9 +9764,9 @@
             words</quote> (for example, rows that contain <quote>some
             words of wisdom</quote> but not <quote>some noise
             words</quote>). Note that the
-            &lsquo;<literal>"</literal>&rsquo; characters that surround
+            &lsquo;<literal>"</literal>&rsquo; characters that enclose
             the phrase are operator characters that delimit the phrase.
-            They are not the quotes that surround the search string
+            They are not the quotes that enclose the search string
             itself.
           </para>
         </listitem>
@@ -9783,8 +9784,8 @@
         its variant <quote>blind query expansion</quote>). This is
         generally useful when a search phrase is too short, which often
         means that the user is relying on implied knowledge that the
-        full-text search engine usually lacks. For example, a user
-        searching for <quote>database</quote> may really mean that
+        full-text search engine lacks. For example, a user searching for
+        <quote>database</quote> may really mean that
         <quote>MySQL</quote>, <quote>Oracle</quote>, <quote>DB2</quote>,
         and <quote>RDBMS</quote> all are phrases that should match
         <quote>databases</quote> and should be returned, too. This is
@@ -9797,12 +9798,13 @@
         EXPANSION</literal> following the search phrase. It works by
         performing the search twice, where the search phrase for the
         second search is the original search phrase concatenated with
-        the few top found documents from the first search. Thus, if one
-        of these documents contains the word <quote>databases</quote>
-        and the word <quote>MySQL</quote>, the second search finds the
-        documents that contain the word <quote>MySQL</quote> even if
-        they do not contain the word <quote>database</quote>. The
-        following example shows this difference:
+        the few most highly relevant documents from the first search.
+        Thus, if one of these documents contains the word
+        <quote>databases</quote> and the word <quote>MySQL</quote>, the
+        second search finds the documents that contain the word
+        <quote>MySQL</quote> even if they do not contain the word
+        <quote>database</quote>. The following example shows this
+        difference:
       </para>
 
 <programlisting>
@@ -10650,7 +10652,7 @@
         <listitem>
           <para>
             Full-text searches can be used with most multi-byte
-            character sets. The exception is that for Unicode; the
+            character sets. The exception is that for Unicode, the
             <literal>utf8</literal> character set can be used, but not
             the <literal>ucs2</literal> character set.
           </para>
@@ -10683,7 +10685,8 @@
             exactly the column list in some <literal>FULLTEXT</literal>
             index definition for the table, unless this
             <literal>MATCH()</literal> is <literal>IN BOOLEAN
-            MODE</literal>.
+            MODE</literal>. Boolean-mode searches can be done on
+            non-indexed columns, although they are likely to be slow.
           </para>
         </listitem>
 
@@ -10713,14 +10716,14 @@
       <para>
         Note that full-text search is carefully tuned for the most
         effectiveness. Modifying the default behavior in most cases can
-        actually decrease it. <emphasis>Do not alter the MySQL sources
-        unless you know what you are doing</emphasis>.
+        actually decrease effectiveness. <emphasis>Do not alter the
+        MySQL sources unless you know what you are doing</emphasis>.
       </para>
 
       <para>
-        Most full-text variables described below must be set at server
-        startup time. A server restart is required to change them; they
-        cannot be modified while the server is running.
+        Most full-text variables described in this section must be set
+        at server startup time. A server restart is required to change
+        them; they cannot be modified while the server is running.
       </para>
 
       <para>
@@ -10733,17 +10736,16 @@
 
         <listitem>
           <para>
-            The minimum and maximum length of words to be indexed is
+            The minimum and maximum lengths of words to be indexed are
             defined by the <literal>ft_min_word_len</literal> and
             <literal>ft_max_word_len</literal> system variables. (See
             <xref linkend="server-system-variables"/>.) The default
-            minimum value is four characters; the default maximum
-            depends on the MySQL version in use. If you change either
-            value, you must rebuild your <literal>FULLTEXT</literal>
-            indexes. For example, if you want three-character words to
-            be searchable, you can set the
-            <literal>ft_min_word_len</literal> variable by putting the
-            following lines in an option file:
+            minimum value is four characters; the default maximum is
+            version dependent. If you change either value, you must
+            rebuild your <literal>FULLTEXT</literal> indexes. For
+            example, if you want three-character words to be searchable,
+            you can set the <literal>ft_min_word_len</literal> variable
+            by putting the following lines in an option file:
           </para>
 
 <programlisting>
@@ -10752,9 +10754,9 @@
 </programlisting>
 
           <para>
-            Then restart the server and rebuild your
-            <literal>FULLTEXT</literal> indexes. Also note particularly
-            the remarks regarding <command>myisamchk</command> in the
+            Then you must restart the server and rebuild your
+            <literal>FULLTEXT</literal> indexes. Note particularly the
+            remarks regarding <command>myisamchk</command> in the
             instructions following this list.
           </para>
         </listitem>
@@ -10777,8 +10779,8 @@
             value should be the pathname of the file containing the
             stopword list, or the empty string to disable stopword
             filtering. After changing the value of this variable or the
-            contents of the stopword file, rebuild your
-            <literal>FULLTEXT</literal> indexes.
+            contents of the stopword file, restart the server and
+            rebuild your <literal>FULLTEXT</literal> indexes.
           </para>
 
           <para>
@@ -10815,12 +10817,12 @@
           <para>
             Then recompile MySQL. There is no need to rebuild the
             indexes in this case. <emphasis role="bold">Note</emphasis>:
-            By doing this you <emphasis>severely</emphasis> decrease
-            MySQL's ability to provide adequate relevance values for the
-            <literal>MATCH()</literal> function. If you really need to
-            search for such common words, it would be better to search
-            using <literal>IN BOOLEAN MODE</literal> instead, which does
-            not observe the 50% threshold.
+            By making this change, you <emphasis>severely</emphasis>
+            decrease MySQL's ability to provide adequate relevance
+            values for the <literal>MATCH()</literal> function. If you
+            really need to search for such common words, it would be
+            better to search using <literal>IN BOOLEAN MODE</literal>
+            instead, which does not observe the 50% threshold.
           </para>
         </listitem>
 
@@ -10828,8 +10830,8 @@
           <para>
             To change the operators used for boolean full-text searches,
             set the <literal>ft_boolean_syntax</literal> system
-            variable. This variable also can be changed while the server
-            is running, but you must have the <literal>SUPER</literal>
+            variable. This variable can be changed while the server is
+            running, but you must have the <literal>SUPER</literal>
             privilege to do so. No rebuilding of indexes is necessary in
             this case. See <xref linkend="server-system-variables"/>,
             which describes the rules governing how to set this
@@ -10858,17 +10860,18 @@
         Note that if you use <command>myisamchk</command> to perform an
         operation that modifies table indexes (such as repair or
         analyze), the <literal>FULLTEXT</literal> indexes are rebuilt
-        using the default full-text parameter values for minimum and
-        maximum word length and the stopword file unless you specify
-        otherwise. This can result in queries failing.
+        using the <emphasis>default</emphasis> full-text parameter
+        values for minimum word length, maximum word length, and
+        stopword file unless you specify otherwise. This can result in
+        queries failing.
       </para>
 
       <para>
         The problem occurs because these parameters are known only by
         the server. They are not stored in <literal>MyISAM</literal>
         index files. To avoid the problem if you have modified the
-        minimum or maximum word length or the stopword file in the
-        server, specify the same <literal>ft_min_word_len</literal>,
+        minimum or maximum word length or stopword file values used by
+        the server, specify the same <literal>ft_min_word_len</literal>,
         <literal>ft_max_word_len</literal>, and
         <literal>ft_stopword_file</literal> values to
         <command>myisamchk</command> that you use for
@@ -10883,8 +10886,8 @@
 
       <para>
         To ensure that <command>myisamchk</command> and the server use
-        the same values for full-text parameters, you can place each one
-        in both the <literal>[mysqld]</literal> and
+        the same values for full-text parameters, place each one in both
+        the <literal>[mysqld]</literal> and
         <literal>[myisamchk]</literal> sections of an option file:
       </para>
 
@@ -10900,9 +10903,9 @@
         An alternative to using <command>myisamchk</command> is to use
         the <literal>REPAIR TABLE</literal>, <literal>ANALYZE
         TABLE</literal>, <literal>OPTIMIZE TABLE</literal>, or
-        <literal>ALTER TABLE</literal>. These statements are performed
-        by the server, which knows the proper full-text parameter values
-        to use.
+        <literal>ALTER TABLE</literal> statements. These statements are
+        performed by the server, which knows the proper full-text
+        parameter values to use.
       </para>
 
     </section>

Modified: trunk/refman-5.0/information-schema.xml
===================================================================
--- trunk/refman-5.0/information-schema.xml	2006-01-21 03:10:02 UTC (rev 962)
+++ trunk/refman-5.0/information-schema.xml	2006-01-21 03:45:12 UTC (rev 963)
@@ -194,8 +194,8 @@
 
   <para>
     In effect, we have a new database named
-    <literal>INFORMATION_SCHEMA</literal>, though there is never a need
-    to make a file by that name. It is possible to select
+    <literal>INFORMATION_SCHEMA</literal>, although there is never a
+    need to make a file by that name. It is possible to select
     <literal>INFORMATION_SCHEMA</literal> as the default database with a
     <literal>USE</literal> statement, but the only way to access the
     contents of its tables is with <literal>SELECT</literal>. You cannot

Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml	2006-01-21 03:10:02 UTC (rev 962)
+++ trunk/refman-5.0/innodb.xml	2006-01-21 03:45:12 UTC (rev 963)
@@ -1220,9 +1220,9 @@
           work regardless of the value. Note that many operating systems
           and some disk hardware fool the flush-to-disk operation. They
           may tell <command>mysqld</command> that the flush has taken
-          place, though it has not. Then the durability of transactions
-          is not guaranteed even with the setting 1, and in the worst
-          case a power outage can even corrupt the
+          place, even though it has not. Then the durability of
+          transactions is not guaranteed even with the setting 1, and in
+          the worst case a power outage can even corrupt the
           <literal>InnoDB</literal> database. Using a battery-backed
           disk cache in the SCSI disk controller or in the disk itself
           speeds up file flushes, and makes the operation safer. You can

Modified: trunk/refman-5.0/storage-engines.xml
===================================================================
--- trunk/refman-5.0/storage-engines.xml	2006-01-21 03:10:02 UTC (rev 962)
+++ trunk/refman-5.0/storage-engines.xml	2006-01-21 03:45:12 UTC (rev 963)
@@ -3465,7 +3465,7 @@
         very simple. Normally, you have two servers running, either both
         on the same host or on different hosts. (It is possible for a
         <literal>FEDERATED</literal> table to use another table that is
-        managed by the same server, though there is little point in
+        managed by the same server, although there is little point in
         doing so.)
       </para>
 

Modified: trunk/refman-5.1/connector-odbc.xml
===================================================================
--- trunk/refman-5.1/connector-odbc.xml	2006-01-21 03:10:02 UTC (rev 962)
+++ trunk/refman-5.1/connector-odbc.xml	2006-01-21 03:45:12 UTC (rev 963)
@@ -2098,12 +2098,12 @@
       <title>&title-data-source-name;</title>
 
       <para>
-        A <firstterm>data source</firstterm> is a place where data comes from. The data
-        source must have a persistent identifier, the Data Source Name.
-        Using the Data Source Name, MySQL can access initialization
-        information. With the initialization information, MySQL knows
-        where to access the database and what settings to use when the
-        access starts.
+        A <firstterm>data source</firstterm> is a place where data comes
+        from. The data source must have a persistent identifier, the
+        Data Source Name. Using the Data Source Name, MySQL can access
+        initialization information. With the initialization information,
+        MySQL knows where to access the database and what settings to
+        use when the access starts.
       </para>
 
       <para>
@@ -2126,13 +2126,15 @@
 
       <para>
         If the information is in the Windows registry, it is called a
-        <firstterm>Machine data source</firstterm>. It might be a <firstterm>User data source</firstterm>, in
-        which case only one user can see it. Or it might be a <firstterm>System
-        data source</firstterm> in which case it is accessible to all users on the
-        computer, or indeed to all users connected to the computer, if
-        the users are connected by Microsoft Windows NT services. When
-        you run the ODBC Data Administration program, you have a choice
-        whether to use "User" or "System" -- there are separate tabs.
+        <firstterm>Machine data source</firstterm>. It might be a
+        <firstterm>User data source</firstterm>, in which case only one
+        user can see it. Or it might be a <firstterm>System data
+        source</firstterm> in which case it is accessible to all users
+        on the computer, or indeed to all users connected to the
+        computer, if the users are connected by Microsoft Windows NT
+        services. When you run the ODBC Data Administration program, you
+        have a choice whether to use "User" or "System" -- there are
+        separate tabs.
       </para>
 
       <para>
@@ -4139,8 +4141,8 @@
             Tested with BDE 3.0. The only known problem is that when the
             table schema changes, query fields are not updated. BDE,
             however, does not seem to recognize primary keys, only the
-            index named <literal>PRIMARY</literal>, though this has not
-            been a problem.
+            index named <literal>PRIMARY</literal>, although this has
+            not been a problem.
           </para>
         </listitem>
 
@@ -4216,7 +4218,7 @@
             Enterprise 2000 to MySQL via MyODBC (2.50.37 or greater) and
             using Visio's reverse engineer function to retrieve
             information about the DB (Visio shows all the column
-            definitions, primary keys, Indexes and so on). Also we
+            definitions, primary keys, indexes and so on). Also, we
             tested by designing new tables in Visio and exported them to
             MySQL via MyODBC.
           </para>

Modified: trunk/refman-5.1/database-administration.xml
===================================================================
--- trunk/refman-5.1/database-administration.xml	2006-01-21 03:10:02 UTC (rev 962)
+++ trunk/refman-5.1/database-administration.xml	2006-01-21 03:45:12 UTC (rev 963)
@@ -7546,7 +7546,7 @@
               Increasing this value increases the number of file
               descriptors that <command>mysqld</command> requires. See
               <xref linkend="table-cache"/>, for comments on file
-              descriptor limits. Also see
+              descriptor limits. See also
               <xref linkend="too-many-connections"/>.
             </para>
           </listitem>

Modified: trunk/refman-5.1/functions.xml
===================================================================
--- trunk/refman-5.1/functions.xml	2006-01-21 03:10:02 UTC (rev 962)
+++ trunk/refman-5.1/functions.xml	2006-01-21 03:45:12 UTC (rev 963)
@@ -7042,7 +7042,7 @@
         <remark role="help-description-begin"/>
 
         <para>
-          Given a daynumber <replaceable>N</replaceable>, returns a
+          Given a day number <replaceable>N</replaceable>, returns a
           <literal>DATE</literal> value.
         </para>
 
@@ -7650,7 +7650,8 @@
           Within a stored routine or trigger, <literal>NOW()</literal>
           returns a constant time that indicates the time at which the
           routine or triggering statement began to execute. This differs
-          from the behavior for <literal>SYSDATE()</literal>.
+          from the behavior for <literal>SYSDATE()</literal>, which
+          returns the exact time at which it executes.
         </para>
       </listitem>
 
@@ -7848,7 +7849,7 @@
         <remark role="help-description-begin"/>
 
         <para>
-          This is the reverse of the <literal>DATE_FORMAT()</literal>
+          This is the inverse of the <literal>DATE_FORMAT()</literal>
           function. It takes a string <replaceable>str</replaceable> and
           a format string <replaceable>format</replaceable>.
           <literal>STR_TO_DATE()</literal> returns a
@@ -7881,12 +7882,10 @@
           <replaceable>str</replaceable> should be given in the format
           indicated by <replaceable>format</replaceable>. For the
           specifiers that can be used in
-          <replaceable>format</replaceable>, see the table in the
-          <literal>DATE_FORMAT()</literal> function description. All
-          other characters are just taken verbatim, thus not being
-          interpreted. If <replaceable>str</replaceable> contains an
-          illegal date, time, or datetime value,
-          <literal>STR_TO_DATE()</literal> returns
+          <replaceable>format</replaceable>, see the
+          <literal>DATE_FORMAT()</literal> function description. If
+          <replaceable>str</replaceable> contains an illegal date, time,
+          or datetime value, <literal>STR_TO_DATE()</literal> returns
           <literal>NULL</literal>. An illegal value also produces a
           warning.
         </para>
@@ -7964,9 +7963,9 @@
 
         <para>
           The second form allows the use of an integer value for
-          <replaceable>days</replaceable>. In such cases, it is reckoned
-          to be the number of days to be subtracted from the date or
-          datetime expression <replaceable>expr</replaceable>.
+          <replaceable>days</replaceable>. In such cases, it is
+          interpreted as the number of days to be subtracted from the
+          date or datetime expression <replaceable>expr</replaceable>.
         </para>
 
 <programlisting>
@@ -7975,17 +7974,17 @@
 </programlisting>
 
         <para>
-          <emphasis role="bold">Note</emphasis> that you cannot use
-          format <literal>"%X%V"</literal> to convert a year-week string
-          to a date as the combination of a year and week does not
+          <emphasis role="bold">Note</emphasis>: You cannot use format
+          <literal>"%X%V"</literal> to convert a year-week string to a
+          date because the combination of a year and week does not
           uniquely identify a year and month if the week crosses a month
           boundary. To convert a year-week to a date, then you should
           also specify the weekday:
         </para>
 
 <programlisting>
-mysql&gt; <userinput>select str_to_date('200442 Monday', '%X%V %W');</userinput>
--&gt; 2004-10-18
+mysql&gt; <userinput>SELECT STR_TO_DATE('200442 Monday', '%X%V %W');</userinput>
+        -&gt; '2004-10-18'
 </programlisting>
 
         <remark role="help-description-end"/>
@@ -8060,9 +8059,9 @@
         <para>
           Within a stored routine or trigger,
           <literal>SYSDATE()</literal> returns the time at which it
-          executes, not the time at which the routine or triggering
-          statement began to execute. This differs from the behavior for
-          <literal>NOW()</literal>.
+          executes. This differs from the behavior for
+          <literal>NOW()</literal>, which returns the the time at which
+          the routine or triggering statement began to execute.
         </para>
 
         <remark role="help-description-end"/>
@@ -8178,7 +8177,7 @@
           datetime value. With two arguments, it adds the time
           expression <replaceable>expr2</replaceable> to the date or
           datetime expression <replaceable>expr</replaceable> and
-          returns theresult as a datetime value.
+          returns the result as a datetime value.
         </para>
 
         <remark role="help-description-end"/>
@@ -8227,7 +8226,7 @@
           The <replaceable>interval</replaceable> value may be specified
           using one of keywords as shown, or with a prefix of
           <literal>SQL_TSI_</literal>. For example,
-          <literal>DAY</literal> or <literal>SQL_TSI_DAY</literal> both
+          <literal>DAY</literal> and <literal>SQL_TSI_DAY</literal> both
           are legal.
         </para>
 
@@ -8303,9 +8302,9 @@
         <para>
           This is used like the <literal>DATE_FORMAT()</literal>
           function, but the <replaceable>format</replaceable> string may
-          contain only those format specifiers that handle hours,
-          minutes, and seconds. Other specifiers produce a
-          <literal>NULL</literal> value or <literal>0</literal>.
+          contain format specifiers only for hours, minutes, and
+          seconds. Other specifiers produce a <literal>NULL</literal>
+          value or <literal>0</literal>.
         </para>
 
         <remark role="help-description-end"/>
@@ -8379,8 +8378,8 @@
         <remark role="help-description-begin"/>
 
         <para>
-          Given a date <replaceable>date</replaceable>, returns a
-          daynumber (the number of days since year 0).
+          Given a date <replaceable>date</replaceable>, returns a day
+          number (the number of days since year 0).
         </para>
 
         <remark role="help-description-end"/>
@@ -8398,8 +8397,10 @@
           <literal>TO_DAYS()</literal> is not intended for use with
           values that precede the advent of the Gregorian calendar
           (1582), because it does not take into account the days that
-          were lost when the calendar was changed. See
-          <xref linkend="mysql-calendar"/>.
+          were lost when the calendar was changed. For dates before 1582
+          (and possibly a later year in other locales), results from
+          this function are not reliable. See
+          <xref linkend="mysql-calendar"/>, for details.
         </para>
 
         <para>
@@ -8414,12 +8415,6 @@
 mysql&gt; <userinput>SELECT TO_DAYS('1997-10-07'), TO_DAYS('97-10-07');</userinput>
         -&gt; 729669, 729669
 </programlisting>
-
-        <para>
-          For dates before 1582 (and possibly a later year in other
-          locales), results from this function are not reliable. See
-          <xref linkend="mysql-calendar"/>, for details.
-        </para>
       </listitem>
 
       <listitem>
@@ -8776,9 +8771,8 @@
         <para>
           If you would prefer the result to be evaluated with respect to
           the year that contains the first day of the week for the given
-          date, you should use <literal>0</literal>,
-          <literal>2</literal>, <literal>5</literal>, or
-          <literal>7</literal> as the optional
+          date, use <literal>0</literal>, <literal>2</literal>,
+          <literal>5</literal>, or <literal>7</literal> as the optional
           <replaceable>mode</replaceable> argument.
         </para>
 
@@ -8853,8 +8847,9 @@
 
         <para>
           Returns the calendar week of the date as a number in the range
-          from <literal>1</literal> to <literal>53</literal>. It is a
-          compatibility function that is equivalent to
+          from <literal>1</literal> to <literal>53</literal>.
+          <literal>WEEKOFYEAR()</literal> is a compatibility function
+          that is equivalent to
           <literal>WEEK(<replaceable>date</replaceable>,3)</literal>.
         </para>
 
@@ -8887,7 +8882,8 @@
 
         <para>
           Returns the year for <replaceable>date</replaceable>, in the
-          range <literal>1000</literal> to <literal>9999</literal>.
+          range <literal>1000</literal> to <literal>9999</literal>, or
+          <literal>0</literal> for the <quote>zero</quote> date.
         </para>
 
         <remark role="help-description-end"/>
@@ -9039,7 +9035,7 @@
       did not occur at the same time in all countries, and that the
       later it happened, the more days were lost. For example, in Great
       Britain, it took place in 1752, when Wednesday September 2 was
-      followed by Thursday September 14; Russia remained on the Julian
+      followed by Thursday September 14. Russia remained on the Julian
       calendar until 1918, losing 13 days in the process, and what is
       popularly referred to as its <quote>October Revolution</quote>
       occurred in November according to the Gregorian calendar.
@@ -9101,15 +9097,15 @@
           full-text index in MySQL is an index of type
           <literal>FULLTEXT</literal>. <literal>FULLTEXT</literal>
           indexes can be used only with <literal>MyISAM</literal>
-          tables; they can be created from <literal>CHAR</literal>,
+          tables. They can be created for <literal>CHAR</literal>,
           <literal>VARCHAR</literal>, or <literal>TEXT</literal> columns
-          as part of a <literal>CREATE TABLE</literal> statement or
-          added later using <literal>ALTER TABLE</literal> or
-          <literal>CREATE INDEX</literal>. For large datasets, it is
-          much faster to load your data into a table that has no
-          <literal>FULLTEXT</literal> index, and then create the index
-          afterwards, than to load data into a table that has an
-          existing <literal>FULLTEXT</literal> index.
+          with <literal>CREATE TABLE</literal> or added later using
+          <literal>ALTER TABLE</literal> or <literal>CREATE
+          INDEX</literal>. For large datasets, it is much faster to load
+          your data into a table that has no <literal>FULLTEXT</literal>
+          index and then create the index afterwards, than to load data
+          into a table that has an existing <literal>FULLTEXT</literal>
+          index.
         </para>
 
         <remark role="help-description-end"/>
@@ -9159,14 +9155,14 @@
 
     <para>
       The <literal>MATCH()</literal> function performs a natural
-      language search for a string against a text collection. A
-      collection is a set of one or more columns included in a
-      <literal>FULLTEXT</literal> index. The search string is given as
-      the argument to <literal>AGAINST()</literal>. For each row in the
-      table, <literal>MATCH()</literal> returns a relevance value, that
-      is, a similarity measure between the search string and the text in
-      that row in the columns named in the <literal>MATCH()</literal>
-      list.
+      language search for a string against a <firstterm>text
+      collection</firstterm>. A collection is a set of one or more
+      columns included in a <literal>FULLTEXT</literal> index. The
+      search string is given as the argument to
+      <literal>AGAINST()</literal>. For each row in the table,
+      <literal>MATCH()</literal> returns a relevance value, that is, a
+      similarity measure between the search string and the text in that
+      row in the columns named in the <literal>MATCH()</literal> list.
     </para>
 
     <para>
@@ -9180,13 +9176,13 @@
 
     <para>
       When <literal>MATCH()</literal> is used in a
-      <literal>WHERE</literal> clause, as in the preceding example, the
-      rows returned are automatically sorted with the highest relevance
-      first. Relevance values are non-negative floating-point numbers.
-      Zero relevance means no similarity. Relevance is computed based on
-      the number of words in the row, the number of unique words in that
-      row, the total number of words in the collection, and the number
-      of documents (rows) that contain a particular word.
+      <literal>WHERE</literal> clause, as in the example shown earlier,
+      the rows returned are automatically sorted with the highest
+      relevance first. Relevance values are non-negative floating-point
+      numbers. Zero relevance means no similarity. Relevance is computed
+      based on the number of words in the row, the number of unique
+      words in that row, the total number of words in the collection,
+      and the number of documents (rows) that contain a particular word.
     </para>
 
     <para>
@@ -9200,7 +9196,7 @@
       <literal>article</literal> table's <literal>FULLTEXT</literal>
       index. If you wanted to search the <literal>title</literal> or
       <literal>body</literal> separately, you would need to create
-      <literal>FULLTEXT</literal> indexes for each column.
+      separate <literal>FULLTEXT</literal> indexes for each column.
     </para>
 
     <para>
@@ -9211,13 +9207,13 @@
     </para>
 
     <para>
-      The preceding example is a basic illustration showing how to use
-      the <literal>MATCH()</literal> function where rows are returned in
-      order of decreasing relevance. The next example shows how to
-      retrieve the relevance values explicitly. Returned rows are not
-      ordered because the <literal>SELECT</literal> statement includes
-      neither <literal>WHERE</literal> nor <literal>ORDER BY</literal>
-      clauses:
+      The preceding example is a basic illustration that shows how to
+      use the <literal>MATCH()</literal> function where rows are
+      returned in order of decreasing relevance. The next example shows
+      how to retrieve the relevance values explicitly. Returned rows are
+      not ordered because the <literal>SELECT</literal> statement
+      includes neither <literal>WHERE</literal> nor <literal>ORDER
+      BY</literal> clauses:
     </para>
 
 <programlisting>
@@ -9278,15 +9274,16 @@
 
     <para>
       The <literal>FULLTEXT</literal> parser determines where words
-      start and end by looking for certain delimiters, for example
-      <literal>' '</literal> (the space character), <literal>,</literal>
-      (the comma), and <literal>.</literal> (the period). If words are
-      not separated by delimiters (as in, for example, Chinese), the
+      start and end by looking for certain delimiter characters; for
+      example, &lsquo;<literal>&nbsp;</literal>&rsquo; (space),
+      &lsquo;<literal>,</literal>&rsquo; (comma), and
+      &lsquo;<literal>.</literal>&rsquo; (period). If words are not
+      separated by delimiters (as in, for example, Chinese), the
       <literal>FULLTEXT</literal> parser cannot determine where a word
       begins or ends. To be able to add words or other indexed terms in
       such languages to a <literal>FULLTEXT</literal> index, you must
       preprocess them so that they are separated by some arbitrary
-      delimiter such as <literal>"</literal>.
+      delimiter such as &lsquo;<literal>"</literal>&rsquo;.
     </para>
 
     <para>
@@ -9317,8 +9314,7 @@
           such as <quote>the</quote> or <quote>some</quote> that is so
           common that it is considered to have zero semantic value.
           There is a built-in stopword list, but it can be overwritten
-          by a user-defined list. See
-          <xref linkend="fulltext-fine-tuning"/>.
+          by a user-defined list.
         </para>
       </listitem>
 
@@ -9337,12 +9333,12 @@
 
     <para>
       Every correct word in the collection and in the query is weighted
-      according to its significance in the collection or query. This
-      way, a word that is present in many documents has a lower weight
-      (and may even have a zero weight), because it has lower semantic
-      value in this particular collection. Conversely, if the word is
-      rare, it receives a higher weight. The weights of the words are
-      then combined to compute the relevance of the row.
+      according to its significance in the collection or query.
+      Consequently, a word that is present in many documents has a lower
+      weight (and may even have a zero weight), because it has lower
+      semantic value in this particular collection. Conversely, if the
+      word is rare, it receives a higher weight. The weights of the
+      words are combined to compute the relevance of the row.
     </para>
 
     <para>
@@ -9351,8 +9347,8 @@
       distribution does not adequately reflect their semantic value, and
       this model may sometimes produce bizarre results. For example,
       although the word <quote>MySQL</quote> is present in every row of
-      the <literal>articles</literal> table, a search for the word
-      produces no results:
+      the <literal>articles</literal> table shown earlier, a search for
+      the word produces no results:
     </para>
 
 <programlisting>
@@ -9365,9 +9361,9 @@
       The search result is empty because the word <quote>MySQL</quote>
       is present in at least 50% of the rows. As such, it is effectively
       treated as a stopword. For large datasets, this is the most
-      desirable behavior &mdash; a natural language query should not
-      return every second row from a 1GB table. For small datasets, it
-      may be less desirable.
+      desirable behavior: A natural language query should not return
+      every second row from a 1GB table. For small datasets, it may be
+      less desirable.
     </para>
 
     <para>
@@ -9397,7 +9393,7 @@
       <title>&title-fulltext-boolean;</title>
 
       <para>
-        MySQL can also perform boolean full-text searches using the
+        MySQL can perform boolean full-text searches using the
         <literal>IN BOOLEAN MODE</literal> modifier:
       </para>
 
@@ -9416,9 +9412,12 @@
 </programlisting>
 
       <para>
-        This query retrieves all the rows that contain the word
-        <quote>MySQL</quote> but that do <emphasis>not</emphasis>
-        contain the word <quote>YourSQL</quote>.
+        The <literal>+</literal> and <literal>-</literal> operators
+        indicate that a word is required to be present or absent,
+        respectively, for a match to occur. Thus, this query retrieves
+        all the rows that contain the word <quote>MySQL</quote> but that
+        do <emphasis>not</emphasis> contain the word
+        <quote>YourSQL</quote>.
       </para>
 
       <para>
@@ -9517,7 +9516,7 @@
 
         <listitem>
           <para>
-            <literal>(no operator)</literal>
+            (no operator)
           </para>
 
           <para>
@@ -9539,7 +9538,7 @@
             to the relevance value that is assigned to a row. The
             <literal>&gt;</literal> operator increases the contribution
             and the <literal>&lt;</literal> operator decreases it. See
-            the example below.
+            the example following this list.
           </para>
         </listitem>
 
@@ -9549,8 +9548,8 @@
           </para>
 
           <para>
-            Parentheses are used to group words into subexpressions.
-            Parenthesized groups can be nested.
+            Parentheses group words into subexpressions. Parenthesized
+            groups can be nested.
           </para>
         </listitem>
 
@@ -9575,9 +9574,11 @@
           </para>
 
           <para>
-            The asterisk serves as the truncation operator. Unlike the
-            other operators, it should be <emphasis>appended</emphasis>
-            to the word to be affected.
+            The asterisk serves as the truncation (or wildcard)
+            operator. Unlike the other operators, it should be
+            <emphasis>appended</emphasis> to the word to be affected.
+            Words match if they begin with the word preceding the
+            <literal>*</literal> operator.
           </para>
         </listitem>
 
@@ -9711,9 +9712,9 @@
             words</quote> (for example, rows that contain <quote>some
             words of wisdom</quote> but not <quote>some noise
             words</quote>). Note that the
-            &lsquo;<literal>"</literal>&rsquo; characters that surround
+            &lsquo;<literal>"</literal>&rsquo; characters that enclose
             the phrase are operator characters that delimit the phrase.
-            They are not the quotes that surround the search string
+            They are not the quotes that enclose the search string
             itself.
           </para>
         </listitem>
@@ -9731,8 +9732,8 @@
         its variant <quote>blind query expansion</quote>). This is
         generally useful when a search phrase is too short, which often
         means that the user is relying on implied knowledge that the
-        full-text search engine usually lacks. For example, a user
-        searching for <quote>database</quote> may really mean that
+        full-text search engine lacks. For example, a user searching for
+        <quote>database</quote> may really mean that
         <quote>MySQL</quote>, <quote>Oracle</quote>, <quote>DB2</quote>,
         and <quote>RDBMS</quote> all are phrases that should match
         <quote>databases</quote> and should be returned, too. This is
@@ -9745,12 +9746,13 @@
         EXPANSION</literal> following the search phrase. It works by
         performing the search twice, where the search phrase for the
         second search is the original search phrase concatenated with
-        the few top found documents from the first search. Thus, if one
-        of these documents contains the word <quote>databases</quote>
-        and the word <quote>MySQL</quote>, the second search finds the
-        documents that contain the word <quote>MySQL</quote> even if
-        they do not contain the word <quote>database</quote>. The
-        following example shows this difference:
+        the few most highly relevant documents from the first search.
+        Thus, if one of these documents contains the word
+        <quote>databases</quote> and the word <quote>MySQL</quote>, the
+        second search finds the documents that contain the word
+        <quote>MySQL</quote> even if they do not contain the word
+        <quote>database</quote>. The following example shows this
+        difference:
       </para>
 
 <programlisting>
@@ -10598,7 +10600,7 @@
         <listitem>
           <para>
             Full-text searches can be used with most multi-byte
-            character sets. The exception is that for Unicode; the
+            character sets. The exception is that for Unicode, the
             <literal>utf8</literal> character set can be used, but not
             the <literal>ucs2</literal> character set.
           </para>
@@ -10631,7 +10633,8 @@
             exactly the column list in some <literal>FULLTEXT</literal>
             index definition for the table, unless this
             <literal>MATCH()</literal> is <literal>IN BOOLEAN
-            MODE</literal>.
+            MODE</literal>. Boolean-mode searches can be done on
+            non-indexed columns, although they are likely to be slow.
           </para>
         </listitem>
 
@@ -10661,14 +10664,14 @@
       <para>
         Note that full-text search is carefully tuned for the most
         effectiveness. Modifying the default behavior in most cases can
-        actually decrease it. <emphasis>Do not alter the MySQL sources
-        unless you know what you are doing</emphasis>.
+        actually decrease effectiveness. <emphasis>Do not alter the
+        MySQL sources unless you know what you are doing</emphasis>.
       </para>
 
       <para>
-        Most full-text variables described below must be set at server
-        startup time. A server restart is required to change them; they
-        cannot be modified while the server is running.
+        Most full-text variables described in this section must be set
+        at server startup time. A server restart is required to change
+        them; they cannot be modified while the server is running.
       </para>
 
       <para>
@@ -10681,17 +10684,16 @@
 
         <listitem>
           <para>
-            The minimum and maximum length of words to be indexed is
+            The minimum and maximum lengths of words to be indexed are
             defined by the <literal>ft_min_word_len</literal> and
             <literal>ft_max_word_len</literal> system variables. (See
             <xref linkend="server-system-variables"/>.) The default
-            minimum value is four characters; the default maximum
-            depends on the MySQL version in use. If you change either
-            value, you must rebuild your <literal>FULLTEXT</literal>
-            indexes. For example, if you want three-character words to
-            be searchable, you can set the
-            <literal>ft_min_word_len</literal> variable by putting the
-            following lines in an option file:
+            minimum value is four characters; the default maximum is
+            version dependent. If you change either value, you must
+            rebuild your <literal>FULLTEXT</literal> indexes. For
+            example, if you want three-character words to be searchable,
+            you can set the <literal>ft_min_word_len</literal> variable
+            by putting the following lines in an option file:
           </para>
 
 <programlisting>
@@ -10700,9 +10702,9 @@
 </programlisting>
 
           <para>
-            Then restart the server and rebuild your
-            <literal>FULLTEXT</literal> indexes. Also note particularly
-            the remarks regarding <command>myisamchk</command> in the
+            Then you must restart the server and rebuild your
+            <literal>FULLTEXT</literal> indexes. Note particularly the
+            remarks regarding <command>myisamchk</command> in the
             instructions following this list.
           </para>
         </listitem>
@@ -10725,8 +10727,8 @@
             value should be the pathname of the file containing the
             stopword list, or the empty string to disable stopword
             filtering. After changing the value of this variable or the
-            contents of the stopword file, rebuild your
-            <literal>FULLTEXT</literal> indexes.
+            contents of the stopword file, restart the server and
+            rebuild your <literal>FULLTEXT</literal> indexes.
           </para>
 
           <para>
@@ -10763,12 +10765,12 @@
           <para>
             Then recompile MySQL. There is no need to rebuild the
             indexes in this case. <emphasis role="bold">Note</emphasis>:
-            By doing this you <emphasis>severely</emphasis> decrease
-            MySQL's ability to provide adequate relevance values for the
-            <literal>MATCH()</literal> function. If you really need to
-            search for such common words, it would be better to search
-            using <literal>IN BOOLEAN MODE</literal> instead, which does
-            not observe the 50% threshold.
+            By making this change, you <emphasis>severely</emphasis>
+            decrease MySQL's ability to provide adequate relevance
+            values for the <literal>MATCH()</literal> function. If you
+            really need to search for such common words, it would be
+            better to search using <literal>IN BOOLEAN MODE</literal>
+            instead, which does not observe the 50% threshold.
           </para>
         </listitem>
 
@@ -10776,8 +10778,8 @@
           <para>
             To change the operators used for boolean full-text searches,
             set the <literal>ft_boolean_syntax</literal> system
-            variable. This variable also can be changed while the server
-            is running, but you must have the <literal>SUPER</literal>
+            variable. This variable can be changed while the server is
+            running, but you must have the <literal>SUPER</literal>
             privilege to do so. No rebuilding of indexes is necessary in
             this case. See <xref linkend="server-system-variables"/>,
             which describes the rules governing how to set this
@@ -10806,17 +10808,18 @@
         Note that if you use <command>myisamchk</command> to perform an
         operation that modifies table indexes (such as repair or
         analyze), the <literal>FULLTEXT</literal> indexes are rebuilt
-        using the default full-text parameter values for minimum and
-        maximum word length and the stopword file unless you specify
-        otherwise. This can result in queries failing.
+        using the <emphasis>default</emphasis> full-text parameter
+        values for minimum word length, maximum word length, and
+        stopword file unless you specify otherwise. This can result in
+        queries failing.
       </para>
 
       <para>
         The problem occurs because these parameters are known only by
         the server. They are not stored in <literal>MyISAM</literal>
         index files. To avoid the problem if you have modified the
-        minimum or maximum word length or the stopword file in the
-        server, specify the same <literal>ft_min_word_len</literal>,
+        minimum or maximum word length or stopword file values used by
+        the server, specify the same <literal>ft_min_word_len</literal>,
         <literal>ft_max_word_len</literal>, and
         <literal>ft_stopword_file</literal> values to
         <command>myisamchk</command> that you use for
@@ -10831,8 +10834,8 @@
 
       <para>
         To ensure that <command>myisamchk</command> and the server use
-        the same values for full-text parameters, you can place each one
-        in both the <literal>[mysqld]</literal> and
+        the same values for full-text parameters, place each one in both
+        the <literal>[mysqld]</literal> and
         <literal>[myisamchk]</literal> sections of an option file:
       </para>
 
@@ -10848,9 +10851,9 @@
         An alternative to using <command>myisamchk</command> is to use
         the <literal>REPAIR TABLE</literal>, <literal>ANALYZE
         TABLE</literal>, <literal>OPTIMIZE TABLE</literal>, or
-        <literal>ALTER TABLE</literal>. These statements are performed
-        by the server, which knows the proper full-text parameter values
-        to use.
+        <literal>ALTER TABLE</literal> statements. These statements are
+        performed by the server, which knows the proper full-text
+        parameter values to use.
       </para>
 
     </section>

Modified: trunk/refman-5.1/information-schema.xml
===================================================================
--- trunk/refman-5.1/information-schema.xml	2006-01-21 03:10:02 UTC (rev 962)
+++ trunk/refman-5.1/information-schema.xml	2006-01-21 03:45:12 UTC (rev 963)
@@ -194,8 +194,8 @@
 
   <para>
     In effect, we have a new database named
-    <literal>INFORMATION_SCHEMA</literal>, though there is never a need
-    to make a file by that name. It is possible to select
+    <literal>INFORMATION_SCHEMA</literal>, although there is never a
+    need to make a file by that name. It is possible to select
     <literal>INFORMATION_SCHEMA</literal> as the default database with a
     <literal>USE</literal> statement, but the only way to access the
     contents of its tables is with <literal>SELECT</literal>. You cannot

Modified: trunk/refman-5.1/innodb.xml
===================================================================
--- trunk/refman-5.1/innodb.xml	2006-01-21 03:10:02 UTC (rev 962)
+++ trunk/refman-5.1/innodb.xml	2006-01-21 03:45:12 UTC (rev 963)
@@ -1216,9 +1216,9 @@
           work regardless of the value. Note that many operating systems
           and some disk hardware fool the flush-to-disk operation. They
           may tell <command>mysqld</command> that the flush has taken
-          place, though it has not. Then the durability of transactions
-          is not guaranteed even with the setting 1, and in the worst
-          case a power outage can even corrupt the
+          place, even though it has not. Then the durability of
+          transactions is not guaranteed even with the setting 1, and in
+          the worst case a power outage can even corrupt the
           <literal>InnoDB</literal> database. Using a battery-backed
           disk cache in the SCSI disk controller or in the disk itself
           speeds up file flushes, and makes the operation safer. You can

Modified: trunk/refman-5.1/storage-engines.xml
===================================================================
--- trunk/refman-5.1/storage-engines.xml	2006-01-21 03:10:02 UTC (rev 962)
+++ trunk/refman-5.1/storage-engines.xml	2006-01-21 03:45:12 UTC (rev 963)
@@ -250,7 +250,7 @@
 
   </itemizedlist>
 
-  <!--<para>
+<!--<para>
     For assistance in choosing a storage engine, see
     <xref linkend="pluggable-storage-choosing"/>.
   </para>-->
@@ -3466,7 +3466,7 @@
         very simple. Normally, you have two servers running, either both
         on the same host or on different hosts. (It is possible for a
         <literal>FEDERATED</literal> table to use another table that is
-        managed by the same server, though there is little point in
+        managed by the same server, although there is little point in
         doing so.)
       </para>
 

Thread
svn commit - mysqldoc@docsrva: r963 - in trunk: . refman-4.1 refman-5.0 refman-5.1paul21 Jan