List:Commits« Previous MessageNext Message »
From:paul Date:January 18 2006 9:11pm
Subject:svn commit - mysqldoc@docsrva: r908 - in trunk: . refman-4.1 refman-5.0 refman-5.1
View as plain text  
Author: paul
Date: 2006-01-18 22:11:43 +0100 (Wed, 18 Jan 2006)
New Revision: 908

Log:
 r2309@kite-hub:  paul | 2006-01-18 15:11:21 -0600
 General revisions.


Modified:
   trunk/
   trunk/refman-4.1/charset.xml
   trunk/refman-4.1/data-types.xml
   trunk/refman-4.1/spatial-extensions.xml
   trunk/refman-5.0/charset.xml
   trunk/refman-5.0/data-types.xml
   trunk/refman-5.0/spatial-extensions.xml
   trunk/refman-5.1/charset.xml
   trunk/refman-5.1/data-types.xml
   trunk/refman-5.1/spatial-extensions.xml


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

Modified: trunk/refman-4.1/charset.xml
===================================================================
--- trunk/refman-4.1/charset.xml	2006-01-18 21:11:29 UTC (rev 907)
+++ trunk/refman-4.1/charset.xml	2006-01-18 21:11:43 UTC (rev 908)
@@ -912,7 +912,7 @@
 
       <para>
         Before MySQL 4.1, <literal>NCHAR</literal> and
-        <literal>CHAR</literal> were synonymous. ANSI SQL defines
+        <literal>CHAR</literal> were synonymous. Standard SQL defines
         <literal>NCHAR</literal> or <literal>NATIONAL CHAR</literal> as
         a way to indicate that a <literal>CHAR</literal> column should
         use some predefined character set. MySQL 4.1 and up uses

Modified: trunk/refman-4.1/data-types.xml
===================================================================
--- trunk/refman-4.1/data-types.xml	2006-01-18 21:11:29 UTC (rev 907)
+++ trunk/refman-4.1/data-types.xml	2006-01-18 21:11:43 UTC (rev 908)
@@ -1004,9 +1004,9 @@
             string with the format <literal>'YYYY-MM-DD
             HH:MM:SS'</literal>. Display widths (used as described in
             the following paragraphs) are no longer supported; the
-            display width is fixed at 19 characters. If you want to
-            obtain the value as a number, you should add
-            <literal>+0</literal> to the timestamp column.
+            display width is fixed at 19 characters. To obtain the value
+            as a number, you should add <literal>+0</literal> to the
+            timestamp column.
           </para>
 
           <para>
@@ -1308,17 +1308,19 @@
             <literal>CHARACTER</literal>. <literal>NATIONAL
             CHAR</literal> (or its equivalent short form,
             <literal>NCHAR</literal>) is the standard SQL way to define
-            that a <literal>CHAR</literal> column should use the default
-            character set. This is the default in MySQL.
+            that a <literal>CHAR</literal> column should use some
+            predefined character set. MySQL 4.1 and up
+            <literal>utf8</literal> as this predefined character set.
+            <xref linkend="charset-national"/>.
           </para>
 
           <para>
             As of MySQL 4.1.2, the <literal>BINARY</literal> attribute
             is shorthand for specifying the binary collation of the
-            column character set. Sorting and comparison is based on
-            numeric character values. Before 4.1.2,
+            column character set. In this case, sorting and comparison
+            are based on numeric character values. Before 4.1.2,
             <literal>BINARY</literal> attribute causes the column to be
-            treated as a binary string. Sorting and comparison is based
+            treated as a binary string. Sorting and comparison are based
             on numeric byte values.
           </para>
 
@@ -1340,27 +1342,26 @@
 
           <para>
             From MySQL 4.1.0 on, the <literal>ASCII</literal> attribute
-            can be specified for <literal>CHAR</literal>. It assigns the
-            <literal>latin1</literal> character set.
+            is shorthand for <literal>CHARACTER SET latin1</literal>.
           </para>
 
           <para>
             From MySQL 4.1.1 on, the <literal>UNICODE</literal>
-            attribute can be specified for <literal>CHAR</literal>. It
-            assigns the <literal>ucs2</literal> character set.
+            attribute is shorthand for <literal>CHARACTER SET
+            ucs2</literal>.
           </para>
 
           <para>
             MySQL allows you to create a column of type
-            <literal>CHAR(0)</literal>. This is mainly useful when you
-            have to be compliant with old applications that depend on
-            the existence of a column but that do not actually use the
-            value. This can also be useful when you need a column that
-            can take only two values: A <literal>CHAR(0)</literal>
-            column that is not defined as <literal>NOT NULL</literal>
-            occupies only one bit and can take only the values
-            <literal>NULL</literal> and <literal>''</literal> (the empty
-            string).
+            <literal>CHAR(0)</literal>. This is useful primarily when
+            you have to be compliant with old applications that depend
+            on the existence of a column but that do not actually use
+            its value. <literal>CHAR(0)</literal> is also quite nice
+            when you need a column that can take only two values: A
+            <literal>CHAR(0)</literal> column that is not defined as
+            <literal>NOT NULL</literal> occupies only one bit and can
+            take only the values <literal>NULL</literal> and
+            <literal>''</literal> (the empty string).
           </para>
         </listitem>
 
@@ -1462,10 +1463,10 @@
           <para>
             As of MySQL 4.1.2, the <literal>BINARY</literal> attribute
             is shorthand for specifying the binary collation of the
-            column character set. Sorting and comparison is based on
-            numeric character values. Before 4.1.2,
+            column character set. In this case, sorting and comparison
+            are based on numeric character values. Before 4.1.2,
             <literal>BINARY</literal> attribute causes the column to be
-            treated as a binary string. Sorting and comparison is based
+            treated as a binary string. Sorting and comparison are based
             on numeric byte values.
           </para>
 
@@ -1611,10 +1612,10 @@
 
           <para>
             Beginning with MySQL 4.1, an optional length
-            <replaceable>M</replaceable> can be given. MySQL will create
-            the column as the smallest <literal>BLOB</literal> type
-            largest enough to hold values <replaceable>M</replaceable>
-            bytes long.
+            <replaceable>M</replaceable> can be given for this type.
+            MySQL creates the column as the smallest
+            <literal>BLOB</literal> type large enough to hold values
+            <replaceable>M</replaceable> bytes long.
           </para>
 
           <remark role="help-description-end"/>
@@ -1646,10 +1647,10 @@
 
           <para>
             Beginning with MySQL 4.1, an optional length
-            <replaceable>M</replaceable> can be given. MySQL will create
-            the column as the smallest <literal>TEXT</literal> type
-            largest enough to hold values <replaceable>M</replaceable>
-            characters long.
+            <replaceable>M</replaceable> can be given for this type.
+            MySQL creates the column as the smallest
+            <literal>TEXT</literal> type large enough to hold values
+            <replaceable>M</replaceable> characters long.
           </para>
 
           <remark role="help-description-end"/>
@@ -1872,6 +1873,11 @@
       the integer types.
     </para>
 
+    <remark role="todo">
+      We'll need a production directive here about how to format the
+      table.
+    </remark>
+
     <informaltable>
       <tgroup cols="4">
         <colspec colwidth="15*"/>
@@ -1965,10 +1971,10 @@
     </para>
 
     <para>
-      The display width does not constrain the range of values that can
-      be stored in the column, nor the number of digits that are
-      displayed for values having a width exceeding that specified for
-      the column.
+      The display width does <emphasis>not</emphasis> constrain the
+      range of values that can be stored in the column, nor the number
+      of digits that are displayed for values having a width exceeding
+      that specified for the column.
     </para>
 
     <para>
@@ -1980,7 +1986,7 @@
       Note that if you store larger values than the display width in an
       integer column, you may experience problems when MySQL generates
       temporary tables for some complicated joins, because in these
-      cases MySQL trusts that the data did fit into the original column
+      cases MySQL assumes that the data fits into the original column
       width.
     </para>
 
@@ -1988,7 +1994,12 @@
       All integer types can have an optional (non-standard) attribute
       <literal>UNSIGNED</literal>. Unsigned values can be used when you
       want to allow only non-negative numbers in a column and you need a
-      larger upper numeric range for the column.
+      larger upper numeric range for the column. For example, if an
+      <literal>INT</literal> column is <literal>UNSIGNED</literal>, the
+      size of the column's range is the same but its endpoints shift
+      from <literal>-2147483648</literal> and
+      <literal>2147483647</literal> up to <literal>0</literal> and
+      <literal>4294967295</literal>.
     </para>
 
     <para>
@@ -2012,15 +2023,16 @@
     </para>
 
     <para>
-      The <literal>FLOAT</literal> type is used to represent approximate
-      numeric data types. The SQL standard allows an optional
+      The <literal>FLOAT</literal> and <literal>DOUBLE</literal> data
+      types are used to represent approximate numeric data values. For
+      <literal>FLOAT</literal> the SQL standard allows an optional
       specification of the precision (but not the range of the exponent)
       in bits following the keyword <literal>FLOAT</literal> in
-      parentheses. The MySQL implementation also supports this optional
-      precision specification, but the precision value is used only to
-      determine storage size. A precision from 0 to 23 results in a
-      four-byte single-precision <literal>FLOAT</literal> column. A
-      precision from 24 to 53 results in an eight-byte double-precision
+      parentheses. MySQL also supports this optional precision
+      specification, but the precision value is used only to determine
+      storage size. A precision from 0 to 23 results in a four-byte
+      single-precision <literal>FLOAT</literal> column. A precision from
+      24 to 53 results in an eight-byte double-precision
       <literal>DOUBLE</literal> column.
     </para>
 
@@ -2060,14 +2072,28 @@
     </para>
 
     <para>
-      The <literal>DECIMAL</literal> and <literal>NUMERIC</literal>
-      types are implemented as the same type by MySQL. They are used to
-      store values for which it is important to preserve exact
-      precision, for example with monetary data. When declaring a column
-      of one of these types, the precision and scale can be (and usually
-      is) specified; for example:
+      The <literal>DECIMAL</literal> and <literal>NUMERIC</literal> data
+      types are used to store exact numeric data values. In MySQL,
+      <literal>NUMERIC</literal> is implemented as
+      <literal>DECIMAL</literal>. These types are used to store values
+      for which it is important to preserve exact precision, for example
+      with monetary data.
     </para>
 
+    <para>
+      Through version 4.1, MySQL stores <literal>DECIMAL</literal> and
+      <literal>NUMERIC</literal> values as strings, rather than in
+      binary format. One character is used for each digit of the value,
+      the decimal point (if the scale is greater than 0), and the
+      &lsquo;<literal>-</literal>&rsquo; sign (for negative numbers).
+    </para>
+
+    <para>
+      When declaring a <literal>DECIMAL</literal> or
+      <literal>NUMERIC</literal> column, the precision and scale can be
+      (and usually is) specified; for example:
+    </para>
+
 <programlisting>
 salary DECIMAL(5,2)
 </programlisting>
@@ -2077,17 +2103,8 @@
       <literal>2</literal> is the scale. The precision represents the
       number of significant digits that are stored for values, and the
       scale represents the number of digits that can be stored following
-      the decimal point.
-    </para>
-
-    <para>
-      Through version 4.1, MySQL stores <literal>DECIMAL</literal> and
-      <literal>NUMERIC</literal> values as strings, rather than in
-      binary. One character is used for each digit of the value, the
-      decimal point (if the scale is greater than 0), and the
-      &lsquo;<literal>-</literal>&rsquo; sign (for negative numbers). If
-      the scale is 0, <literal>DECIMAL</literal> and
-      <literal>NUMERIC</literal> values contain no decimal point or
+      the decimal point. If the scale is 0, <literal>DECIMAL</literal>
+      and <literal>NUMERIC</literal> values contain no decimal point or
       fractional part.
     </para>
 
@@ -2164,35 +2181,18 @@
     </para>
 
     <para>
-      For example, the range of an <literal>INT</literal> column is
-      <literal>-2147483648</literal> to <literal>2147483647</literal>.
-      If you try to insert <literal>-9999999999</literal> into an
-      <literal>INT</literal> column, MySQL clips the value to the lower
-      endpoint of the range and stores <literal>-2147483648</literal>
-      instead. Similarly, if you try to insert
-      <literal>9999999999</literal>, MySQL clips the value to the upper
-      endpoint of the range and stores <literal>2147483647</literal>
-      instead.
+      For example, when an out-of-range value is assigned to an integer
+      column, MySQL stores the value representing the corresponding
+      endpoint of the column data type range. If you store 256 into a
+      <literal>TINYINT</literal> or <literal>TINYINT UNSIGNED</literal>
+      column, MySQL stores 255 or 127, respectively. When a
+      floating-point or fixed-point column is assigned a value that
+      exceeds the range implied by the specified (or default) precision
+      and scale, MySQL stores the value representing the corresponding
+      endpoint of that range.
     </para>
 
     <para>
-      If the <literal>INT</literal> column is
-      <literal>UNSIGNED</literal>, the size of the column's range is the
-      same but its endpoints shift up to <literal>0</literal> and
-      <literal>4294967295</literal>. If you try to store
-      <literal>-9999999999</literal> and <literal>9999999999</literal>,
-      the values stored in the column are <literal>0</literal> and
-      <literal>4294967296</literal>.
-    </para>
-
-    <para>
-      When a floating-point or fixed-point column is assigned a value
-      that exceeds the range implied by the specified (or default)
-      precision and scale, MySQL stores the value representing the
-      corresponding end point of that range.
-    </para>
-
-    <para>
       Conversions that occur due to clipping are reported as
       <quote>warnings</quote> for <literal>ALTER TABLE</literal>,
       <literal>LOAD DATA INFILE</literal>, <literal>UPDATE</literal>,
@@ -2324,13 +2324,13 @@
 
       <listitem>
         <para>
-          When MySQL encounters a value for a date or time type that is
-          out of range or otherwise illegal for the type (as described
-          at the beginning of this section), it converts the value to
-          the <quote>zero</quote> value for that type. The exception is
-          that out-of-range <literal>TIME</literal> values are clipped
-          to the appropriate endpoint of the <literal>TIME</literal>
-          range.
+          By default, when MySQL encounters a value for a date or time
+          type that is out of range or otherwise illegal for the type
+          (as described at the beginning of this section), it converts
+          the value to the <quote>zero</quote> value for that type. The
+          exception is that out-of-range <literal>TIME</literal> values
+          are clipped to the appropriate endpoint of the
+          <literal>TIME</literal> range.
         </para>
 
         <informaltable>
@@ -4024,7 +4024,7 @@
         <literal>VARCHAR</literal>, except that they contain binary
         strings rather than non-binary strings. That is, they contain
         byte strings rather than character strings. This means that they
-        have no character set, and sorting and comparison is based on
+        have no character set, and sorting and comparison are based on
         the numeric values of the bytes in column values.
       </para>
 

Modified: trunk/refman-4.1/spatial-extensions.xml
===================================================================
--- trunk/refman-4.1/spatial-extensions.xml	2006-01-18 21:11:29 UTC (rev 907)
+++ trunk/refman-4.1/spatial-extensions.xml	2006-01-18 21:11:43 UTC (rev 908)
@@ -735,7 +735,7 @@
         <listitem>
           <para>
             A <literal>Curve</literal> is closed if its start point is
-            equal to its end point.
+            equal to its endpoint.
           </para>
         </listitem>
 
@@ -748,7 +748,7 @@
         <listitem>
           <para>
             The boundary of a non-closed <literal>Curve</literal>
-            consists of its two end points.
+            consists of its two endpoints.
           </para>
         </listitem>
 
@@ -3414,7 +3414,7 @@
             </para>
 
             <para>
-              Returns the <literal>Point</literal> that is the end point
+              Returns the <literal>Point</literal> that is the endpoint
               of the <literal>LineString</literal> value
               <replaceable>ls</replaceable>.
             </para>

Modified: trunk/refman-5.0/charset.xml
===================================================================
--- trunk/refman-5.0/charset.xml	2006-01-18 21:11:29 UTC (rev 907)
+++ trunk/refman-5.0/charset.xml	2006-01-18 21:11:43 UTC (rev 908)
@@ -898,7 +898,7 @@
       <title>&title-charset-national;</title>
 
       <para>
-        ANSI SQL defines <literal>NCHAR</literal> or <literal>NATIONAL
+        Standard SQL defines <literal>NCHAR</literal> or <literal>NATIONAL
         CHAR</literal> as a way to indicate that a
         <literal>CHAR</literal> column should use some predefined
         character set. MySQL &current-series; uses

Modified: trunk/refman-5.0/data-types.xml
===================================================================
--- trunk/refman-5.0/data-types.xml	2006-01-18 21:11:29 UTC (rev 907)
+++ trunk/refman-5.0/data-types.xml	2006-01-18 21:11:43 UTC (rev 908)
@@ -1038,9 +1038,9 @@
           <para>
             A <literal>TIMESTAMP</literal> value is returned as a string
             in the format <literal>'YYYY-MM-DD HH:MM:SS'</literal> whose
-            display width is fixed at 19 characters. If you want to
-            obtain the value as a number, you should add
-            <literal>+0</literal> to the timestamp column.
+            display width is fixed at 19 characters. To obtain the value
+            as a number, you should add <literal>+0</literal> to the
+            timestamp column.
           </para>
 
           <para>
@@ -1325,16 +1325,29 @@
             <literal>CHARACTER</literal>. <literal>NATIONAL
             CHAR</literal> (or its equivalent short form,
             <literal>NCHAR</literal>) is the standard SQL way to define
-            that a <literal>CHAR</literal> column should use the default
-            character set. This is the default in MySQL.
+            that a <literal>CHAR</literal> column should use some
+            predefined character set. MySQL 4.1 and up
+            <literal>utf8</literal> as this predefined character set.
+            <xref linkend="charset-national"/>.
           </para>
 
           <para>
             The <literal>BINARY</literal> attribute is shorthand for
             specifying the binary collation of the column character set.
-            Sorting and comparison is based on numeric character values.
+            In this case, sorting and comparison are based on numeric
+            character values.
           </para>
 
+          <para>
+            The <literal>ASCII</literal> attribute is shorthand for
+            <literal>CHARACTER SET latin1</literal>.
+          </para>
+
+          <para>
+            The <literal>UNICODE</literal> attribute is shorthand for
+            <literal>CHARACTER SET ucs2</literal>.
+          </para>
+
           <remark role="help-topic" condition="CHAR BYTE"/>
 
           <remark role="help-keywords">
@@ -1352,28 +1365,16 @@
           <remark role="help-description-end"/>
 
           <para>
-            The <literal>ASCII</literal> attribute can be specified for
-            <literal>CHAR</literal>. It assigns the
-            <literal>latin1</literal> character set.
-          </para>
-
-          <para>
-            The <literal>UNICODE</literal> attribute can be specified
-            for <literal>CHAR</literal>. It assigns the
-            <literal>ucs2</literal> character set.
-          </para>
-
-          <para>
             MySQL allows you to create a column of type
-            <literal>CHAR(0)</literal>. This is mainly useful when you
-            have to be compliant with some old applications that depend
+            <literal>CHAR(0)</literal>. This is useful primarily when
+            you have to be compliant with old applications that depend
             on the existence of a column but that do not actually use
-            the value. This is also quite nice when you need a column
-            that can take only two values: A <literal>CHAR(0)</literal>
-            column that is not defined as <literal>NOT NULL</literal>
-            occupies only one bit and can take only the values
-            <literal>NULL</literal> and <literal>''</literal> (the empty
-            string).
+            its value. <literal>CHAR(0)</literal> is also quite nice
+            when you need a column that can take only two values: A
+            <literal>CHAR(0)</literal> column that is not defined as
+            <literal>NOT NULL</literal> occupies only one bit and can
+            take only the values <literal>NULL</literal> and
+            <literal>''</literal> (the empty string).
           </para>
         </listitem>
 
@@ -1481,14 +1482,16 @@
           <para>
             The <literal>BINARY</literal> attribute is shorthand for
             specifying the binary collation of the column character set.
-            Sorting and comparison is based on numeric character values.
+            In this case, sorting and comparison are based on numeric
+            character values.
           </para>
 
           <para>
             Starting from MySQL 5.0.3, <literal>VARCHAR</literal> is
-            stored with a one-byte or two-byte length prefix + data. The
-            length prefix is two bytes if the <literal>VARCHAR</literal>
-            column is declared with a length greater than 255.
+            stored with a one-byte or two-byte length prefix plus data.
+            The length prefix is two bytes if the
+            <literal>VARCHAR</literal> column is declared with a length
+            greater than 255.
           </para>
 
           <remark role="help-description-end"/>
@@ -1625,9 +1628,9 @@
 
           <para>
             An optional length <replaceable>M</replaceable> can be given
-            for this type. If this is done, MySQL will create the column
-            as the smallest <literal>BLOB</literal> type large enough to
-            hold values of <replaceable>M</replaceable> bytes.
+            for this type. If this is done, MySQL creates the column as
+            the smallest <literal>BLOB</literal> type large enough to
+            hold values <replaceable>M</replaceable> bytes long.
           </para>
 
           <remark role="help-description-end"/>
@@ -1658,10 +1661,10 @@
           </para>
 
           <para>
-            An optional length <replaceable>M</replaceable> can be
-            given. Then MySQL will create the column as the smallest
-            <literal>TEXT</literal> type large enough to hold values
-            <replaceable>M</replaceable> characters long.
+            An optional length <replaceable>M</replaceable> can be given
+            for this type. If this is done, MySQL creates the column as
+            the smallest <literal>TEXT</literal> type large enough to
+            hold values <replaceable>M</replaceable> characters long.
           </para>
 
           <remark role="help-description-end"/>
@@ -1890,6 +1893,11 @@
       the integer types.
     </para>
 
+    <remark role="todo">
+      We'll need a production directive here about how to format the
+      table.
+    </remark>
+
     <informaltable>
       <tgroup cols="4">
         <colspec colwidth="15*"/>
@@ -1983,10 +1991,10 @@
     </para>
 
     <para>
-      The display width does not constrain the range of values that can
-      be stored in the column, nor the number of digits that are
-      displayed for values having a width exceeding that specified for
-      the column.
+      The display width does <emphasis>not</emphasis> constrain the
+      range of values that can be stored in the column, nor the number
+      of digits that are displayed for values having a width exceeding
+      that specified for the column.
     </para>
 
     <para>
@@ -1998,7 +2006,7 @@
       Note that if you store larger values than the display width in an
       integer column, you may experience problems when MySQL generates
       temporary tables for some complicated joins, because in these
-      cases MySQL trusts that the data did fit into the original column
+      cases MySQL assumes that the data fits into the original column
       width.
     </para>
 
@@ -2006,7 +2014,12 @@
       All integer types can have an optional (non-standard) attribute
       <literal>UNSIGNED</literal>. Unsigned values can be used when you
       want to allow only non-negative numbers in a column and you need a
-      larger upper numeric range for the column.
+      larger upper numeric range for the column. For example, if an
+      <literal>INT</literal> column is <literal>UNSIGNED</literal>, the
+      size of the column's range is the same but its endpoints shift
+      from <literal>-2147483648</literal> and
+      <literal>2147483647</literal> up to <literal>0</literal> and
+      <literal>4294967295</literal>.
     </para>
 
     <para>
@@ -2030,15 +2043,16 @@
     </para>
 
     <para>
-      The <literal>FLOAT</literal> type is used to represent approximate
-      numeric data types. The SQL standard allows an optional
+      The <literal>FLOAT</literal> and <literal>DOUBLE</literal> data
+      types are used to represent approximate numeric data values. For
+      <literal>FLOAT</literal> the SQL standard allows an optional
       specification of the precision (but not the range of the exponent)
       in bits following the keyword <literal>FLOAT</literal> in
-      parentheses. The MySQL implementation also supports this optional
-      precision specification, but the precision value is used only to
-      determine storage size. A precision from 0 to 23 results in a
-      four-byte single-precision <literal>FLOAT</literal> column. A
-      precision from 24 to 53 results in an eight-byte double-precision
+      parentheses. MySQL also supports this optional precision
+      specification, but the precision value is used only to determine
+      storage size. A precision from 0 to 23 results in a four-byte
+      single-precision <literal>FLOAT</literal> column. A precision from
+      24 to 53 results in an eight-byte double-precision
       <literal>DOUBLE</literal> column.
     </para>
 
@@ -2078,14 +2092,29 @@
     </para>
 
     <para>
-      The <literal>DECIMAL</literal> and <literal>NUMERIC</literal>
-      types are implemented as the same type by MySQL. They are used to
-      store values for which it is important to preserve exact
-      precision, for example with monetary data. When declaring a column
-      of one of these types, the precision and scale can be (and usually
-      is) specified; for example:
+      The <literal>DECIMAL</literal> and <literal>NUMERIC</literal> data
+      types are used to store exact numeric data values. In MySQL,
+      <literal>NUMERIC</literal> is implemented as
+      <literal>DECIMAL</literal>. These types are used to store values
+      for which it is important to preserve exact precision, for example
+      with monetary data.
     </para>
 
+    <para>
+      As of MySQL 5.0.3, <literal>DECIMAL</literal> and
+      <literal>NUMERIC</literal> values are stored in binary format.
+      Previously, they were stored as strings, with one character used
+      for each digit of the value, the decimal point (if the scale is
+      greater than 0), and the &lsquo;<literal>-</literal>&rsquo; sign
+      (for negative numbers). See <xref linkend="precision-math"/>.
+    </para>
+
+    <para>
+      When declaring a <literal>DECIMAL</literal> or
+      <literal>NUMERIC</literal> column, the precision and scale can be
+      (and usually is) specified; for example:
+    </para>
+
 <programlisting>
 salary DECIMAL(5,2)
 </programlisting>
@@ -2095,19 +2124,8 @@
       <literal>2</literal> is the scale. The precision represents the
       number of significant digits that are stored for values, and the
       scale represents the number of digits that can be stored following
-      the decimal point.
-    </para>
-
-    <para>
-      As of MySQL 5.0.3, <literal>DECIMAL</literal> and
-      <literal>NUMERIC</literal> values are stored in binary format.
-      Before 5.0.3, MySQL stores <literal>DECIMAL</literal> and
-      <literal>NUMERIC</literal> values as strings, rather than in
-      binary. One character is used for each digit of the value, the
-      decimal point (if the scale is greater than 0), and the
-      &lsquo;<literal>-</literal>&rsquo; sign (for negative numbers). If
-      the scale is 0, <literal>DECIMAL</literal> and
-      <literal>NUMERIC</literal> values contain no decimal point or
+      the decimal point. If the scale is 0, <literal>DECIMAL</literal>
+      and <literal>NUMERIC</literal> values contain no decimal point or
       fractional part.
     </para>
 
@@ -2132,10 +2150,10 @@
       Similarly, the syntax <literal>DECIMAL</literal> is equivalent to
       <literal>DECIMAL(<replaceable>M</replaceable>,0)</literal>, where
       the implementation is allowed to decide the value of
-      <replaceable>M</replaceable>. Both of these variant forms of the
-      <literal>DECIMAL</literal> and <literal>NUMERIC</literal> data
-      types are supported in MySQL &current-series;. The default value
-      of <replaceable>M</replaceable> is 10.
+      <replaceable>M</replaceable>. MySQL supports both of these variant
+      forms of the <literal>DECIMAL</literal> and
+      <literal>NUMERIC</literal> syntax. The default value of
+      <replaceable>M</replaceable> is 10.
     </para>
 
     <para>
@@ -2155,8 +2173,8 @@
     </para>
 
     <para>
-      As of MySQL 5.0.3, the <literal>BIT</literal> data type can be
-      used to store bit-field values. A type of
+      As of MySQL 5.0.3, the <literal>BIT</literal> data type is used to
+      store bit-field values. A type of
       <literal>BIT(<replaceable>M</replaceable>)</literal> allows for
       storage of <replaceable>M</replaceable>-bit values.
       <replaceable>M</replaceable> can range from 1 to 64.
@@ -2184,49 +2202,24 @@
     <para>
       When asked to store a value in a numeric column that is outside
       the data type's allowable range, MySQL's behavior depends on the
-      SQL mode in effect at the time. If the mode is not set, MySQL
-      clips the value to the appropriate endpoint of the range and
-      stores the resulting value instead. However, if the mode is set to
-      <literal>traditional</literal> (<quote>strict mode</quote>), a
-      value that is out of range is rejected with an error, and the
-      insert fails, in accordance with the SQL standard. See
-      <xref linkend="server-sql-mode"/>.
+      SQL mode in effect at the time. For example, if no restrictive
+      modes are enabled, MySQL clips the value to the appropriate
+      endpoint of the range and stores the resulting value instead.
+      However, if the mode is set to <literal>TRADITIONAL</literal>,
+      MySQL rejects a value that is out of range with an error, and the
+      insert fails, in accordance with the SQL standard.
     </para>
 
-    <remark role="todo">
-      [js] Add new example(s) once Bug#11546 is (really) fixed.
-      Grrrrrrrr...!
-    </remark>
-
-<!--
     <para>
-      For example, the range of an <literal>INT</literal> column is
-      <literal>-2147483648</literal> to <literal>2147483647</literal>.
-      If you try to insert <literal>-9999999999</literal> into an
-      <literal>INT</literal> column, MySQL clips the value to the lower
-      endpoint of the range and stores <literal>-2147483648</literal>
-      instead. Similarly, if you try to insert
-      <literal>9999999999</literal>, MySQL clips the value to the upper
-      endpoint of the range and stores <literal>2147483647</literal>
-      instead. If you set ...
-    </para>
--->
-
-    <para>
-      If the <literal>INT</literal> column is
-      <literal>UNSIGNED</literal>, the size of the column's range is the
-      same but its endpoints shift up to <literal>0</literal> and
-      <literal>4294967295</literal>. If you try to store
-      <literal>-9999999999</literal> and <literal>9999999999</literal>,
-      the values stored in the column are <literal>0</literal> and
-      <literal>4294967296</literal> in non-strict mode.
-    </para>
-
-    <para>
+      In non-strict mode, when an out-of-range value is assigned to an
+      integer column, MySQL stores the value representing the
+      corresponding endpoint of the column data type range. If you store
+      256 into a <literal>TINYINT</literal> or <literal>TINYINT
+      UNSIGNED</literal> column, MySQL stores 255 or 127, respectively.
       When a floating-point or fixed-point column is assigned a value
       that exceeds the range implied by the specified (or default)
-      precision and scale, MySQL in non-strict mode stores the value
-      representing the corresponding end point of that range.
+      precision and scale, MySQL stores the value representing the
+      corresponding endpoint of that range.
     </para>
 
     <para>
@@ -2237,8 +2230,8 @@
       <literal>INSERT</literal> statements. When MySQL is operating in
       strict mode, these statements fail, and some or all of the values
       will not be inserted or changed, depending on whether the table is
-      a transactional table and other factors. See
-      <xref linkend="server-sql-mode"/>, for details.
+      a transactional table and other factors. For details, see
+      <xref linkend="server-sql-mode"/>.
     </para>
 
   </section>
@@ -2270,17 +2263,20 @@
 
     <para>
       Starting from MySQL 5.0.2, MySQL gives warnings or errors if you
-      try to insert an illegal date. You can get MySQL to accept certain
-      dates, such as <literal>'1999-11-31'</literal>, by using the
-      <literal>ALLOW_INVALID_DATES</literal> SQL mode. (Before 5.0.2,
-      this mode was the default behavior for MySQL). This is useful when
-      you want to store a <quote>possibly wrong</quote> value which the
-      user has specified (for example, in a web form) in the database
-      for future processing. Under this mode, MySQL verifies only that
-      the month is in the range from 0 to 12 and that the day is in the
-      range from 0 to 31. These ranges are defined to include zero
-      because MySQL allows you to store dates where the day or month and
-      day are zero in a <literal>DATE</literal> or
+      try to insert an illegal date. By setting the SQL mode to the
+      appropriate value, you can specify more exactly what kind of dates
+      you want MySQL to support. (See
+      <xref linkend="server-sql-mode"/>.) You can get MySQL to accept
+      certain dates, such as <literal>'1999-11-31'</literal>, by using
+      the <literal>ALLOW_INVALID_DATES</literal> SQL mode. (Before
+      5.0.2, this mode was the default behavior for MySQL.) This is
+      useful when you want to store a <quote>possibly wrong</quote>
+      value which the user has specified (for example, in a web form) in
+      the database for future processing. Under this mode, MySQL
+      verifies only that the month is in the range from 0 to 12 and that
+      the day is in the range from 0 to 31. These ranges are defined to
+      include zero because MySQL allows you to store dates where the day
+      or month and day are zero in a <literal>DATE</literal> or
       <literal>DATETIME</literal> column. This is extremely useful for
       applications that need to store a birthdate for which you do not
       know the exact date. In this case, you simply store the date as
@@ -2302,12 +2298,6 @@
     </para>
 
     <para>
-      By setting the <literal>sql_mode</literal> system variable to the
-      appropriate mode values, You can more exactly what kind of dates
-      you want MySQL to support. See <xref linkend="server-sql-mode"/>.
-    </para>
-
-    <para>
       Here are some general considerations to keep in mind when working
       with date and time types:
     </para>
@@ -2374,13 +2364,13 @@
 
       <listitem>
         <para>
-          When MySQL encounters a value for a date or time type that is
-          out of range or otherwise illegal for the type (as described
-          at the beginning of this section), it converts the value to
-          the <quote>zero</quote> value for that type. The exception is
-          that out-of-range <literal>TIME</literal> values are clipped
-          to the appropriate endpoint of the <literal>TIME</literal>
-          range.
+          By default, when MySQL encounters a value for a date or time
+          type that is out of range or otherwise illegal for the type
+          (as described at the beginning of this section), it converts
+          the value to the <quote>zero</quote> value for that type. The
+          exception is that out-of-range <literal>TIME</literal> values
+          are clipped to the appropriate endpoint of the
+          <literal>TIME</literal> range.
         </para>
 
         <para>
@@ -3755,7 +3745,7 @@
         <literal>VARCHAR</literal>, except that they contain binary
         strings rather than non-binary strings. That is, they contain
         byte strings rather than character strings. This means that they
-        have no character set, and sorting and comparison is based on
+        have no character set, and sorting and comparison are based on
         the numeric values of the bytes in column values.
       </para>
 

Modified: trunk/refman-5.0/spatial-extensions.xml
===================================================================
--- trunk/refman-5.0/spatial-extensions.xml	2006-01-18 21:11:29 UTC (rev 907)
+++ trunk/refman-5.0/spatial-extensions.xml	2006-01-18 21:11:43 UTC (rev 908)
@@ -751,7 +751,7 @@
         <listitem>
           <para>
             A <literal>Curve</literal> is closed if its start point is
-            equal to its end point.
+            equal to its endpoint.
           </para>
         </listitem>
 
@@ -764,7 +764,7 @@
         <listitem>
           <para>
             The boundary of a non-closed <literal>Curve</literal>
-            consists of its two end points.
+            consists of its two endpoints.
           </para>
         </listitem>
 
@@ -3435,7 +3435,7 @@
             </para>
 
             <para>
-              Returns the <literal>Point</literal> that is the end point
+              Returns the <literal>Point</literal> that is the endpoint
               of the <literal>LineString</literal> value
               <replaceable>ls</replaceable>.
             </para>

Modified: trunk/refman-5.1/charset.xml
===================================================================
--- trunk/refman-5.1/charset.xml	2006-01-18 21:11:29 UTC (rev 907)
+++ trunk/refman-5.1/charset.xml	2006-01-18 21:11:43 UTC (rev 908)
@@ -898,7 +898,7 @@
       <title>&title-charset-national;</title>
 
       <para>
-        ANSI SQL defines <literal>NCHAR</literal> or <literal>NATIONAL
+        Standard SQL defines <literal>NCHAR</literal> or <literal>NATIONAL
         CHAR</literal> as a way to indicate that a
         <literal>CHAR</literal> column should use some predefined
         character set. MySQL &current-series; uses

Modified: trunk/refman-5.1/data-types.xml
===================================================================
--- trunk/refman-5.1/data-types.xml	2006-01-18 21:11:29 UTC (rev 907)
+++ trunk/refman-5.1/data-types.xml	2006-01-18 21:11:43 UTC (rev 908)
@@ -994,9 +994,9 @@
           <para>
             A <literal>TIMESTAMP</literal> value is returned as a string
             in the format <literal>'YYYY-MM-DD HH:MM:SS'</literal> whose
-            display width is fixed at 19 characters. If you want to
-            obtain the value as a number, you should add
-            <literal>+0</literal> to the timestamp column.
+            display width is fixed at 19 characters. To obtain the value
+            as a number, you should add <literal>+0</literal> to the
+            timestamp column.
           </para>
 
           <para>
@@ -1095,13 +1095,6 @@
       </para>
 
       <para>
-        In some cases, MySQL may change a string column to a type
-        different from that given in a <literal>CREATE TABLE</literal>
-        or <literal>ALTER TABLE</literal> statement. See
-        <xref linkend="silent-column-changes"/>.
-      </para>
-
-      <para>
         In MySQL 4.1 and up, string data types include some features
         that you may not have encountered in working with previous
         versions of MySQL (prior to 4.1):
@@ -1268,16 +1261,29 @@
             <literal>CHARACTER</literal>. <literal>NATIONAL
             CHAR</literal> (or its equivalent short form,
             <literal>NCHAR</literal>) is the standard SQL way to define
-            that a <literal>CHAR</literal> column should use the default
-            character set. This is the default in MySQL.
+            that a <literal>CHAR</literal> column should use some
+            predefined character set. MySQL 4.1 and up
+            <literal>utf8</literal> as this predefined character set.
+            <xref linkend="charset-national"/>.
           </para>
 
           <para>
             The <literal>BINARY</literal> attribute is shorthand for
             specifying the binary collation of the column character set.
-            Sorting and comparison is based on numeric character values.
+            In this case, sorting and comparison are based on numeric
+            character values.
           </para>
 
+          <para>
+            The <literal>ASCII</literal> attribute is shorthand for
+            <literal>CHARACTER SET latin1</literal>.
+          </para>
+
+          <para>
+            The <literal>UNICODE</literal> attribute is shorthand for
+            <literal>CHARACTER SET ucs2</literal>.
+          </para>
+
           <remark role="help-topic" condition="CHAR BYTE"/>
 
           <remark role="help-keywords">
@@ -1295,28 +1301,16 @@
           <remark role="help-description-end"/>
 
           <para>
-            The <literal>ASCII</literal> attribute can be specified for
-            <literal>CHAR</literal>. It assigns the
-            <literal>latin1</literal> character set.
-          </para>
-
-          <para>
-            The <literal>UNICODE</literal> attribute can be specified
-            for <literal>CHAR</literal>. It assigns the
-            <literal>ucs2</literal> character set.
-          </para>
-
-          <para>
             MySQL allows you to create a column of type
-            <literal>CHAR(0)</literal>. This is mainly useful when you
-            have to be compliant with some old applications that depend
+            <literal>CHAR(0)</literal>. This is useful primarily when
+            you have to be compliant with old applications that depend
             on the existence of a column but that do not actually use
-            the value. This is also quite nice when you need a column
-            that can take only two values: A <literal>CHAR(0)</literal>
-            column that is not defined as <literal>NOT NULL</literal>
-            occupies only one bit and can take only the values
-            <literal>NULL</literal> and <literal>''</literal> (the empty
-            string).
+            its value. <literal>CHAR(0)</literal> is also quite nice
+            when you need a column that can take only two values: A
+            <literal>CHAR(0)</literal> column that is not defined as
+            <literal>NOT NULL</literal> occupies only one bit and can
+            take only the values <literal>NULL</literal> and
+            <literal>''</literal> (the empty string).
           </para>
         </listitem>
 
@@ -1398,7 +1392,7 @@
             <emphasis role="bold">Note</emphasis>: MySQL
             &current-series; follows the standard SQL specification, and
             does <emphasis>not</emphasis> remove trailing spaces from
-            VARCHAR values.
+            <literal>VARCHAR</literal> values.
           </para>
 
           <para>
@@ -1409,12 +1403,13 @@
           <para>
             The <literal>BINARY</literal> attribute is shorthand for
             specifying the binary collation of the column character set.
-            Sorting and comparison is based on numeric character values.
+            In this case, sorting and comparison are based on numeric
+            character values.
           </para>
 
           <para>
             <literal>VARCHAR</literal> is stored with a one-byte or
-            two-byte length prefix + data. The length prefix is two
+            two-byte length prefix plus data. The length prefix is two
             bytes if the <literal>VARCHAR</literal> column is declared
             with a length greater than 255.
           </para>
@@ -1553,9 +1548,9 @@
 
           <para>
             An optional length <replaceable>M</replaceable> can be given
-            for this type. If this is done, MySQL will create the column
-            as the smallest <literal>BLOB</literal> type large enough to
-            hold values of <replaceable>M</replaceable> bytes.
+            for this type. If this is done, MySQL creates the column as
+            the smallest <literal>BLOB</literal> type large enough to
+            hold values <replaceable>M</replaceable> bytes long.
           </para>
 
           <remark role="help-description-end"/>
@@ -1586,10 +1581,10 @@
           </para>
 
           <para>
-            An optional length <replaceable>M</replaceable> can be
-            given. Then MySQL will create the column as the smallest
-            <literal>TEXT</literal> type large enough to hold values
-            <replaceable>M</replaceable> characters long.
+            An optional length <replaceable>M</replaceable> can be given
+            for this type. If this is done, MySQL creates the column as
+            the smallest <literal>TEXT</literal> type large enough to
+            hold values <replaceable>M</replaceable> characters long.
           </para>
 
           <remark role="help-description-end"/>
@@ -1802,7 +1797,7 @@
 
     <para>
       The <literal>BIT</literal> data type stores bit-field values and
-      is supported for <literal>MyISAM</literal>.
+      is supported for <literal>MyISAM</literal>,
       <literal>MEMORY</literal>, <literal>InnoDB</literal>, and
       <literal>BDB</literal> tables.
     </para>
@@ -1815,6 +1810,11 @@
       the integer types.
     </para>
 
+    <remark role="todo">
+      We'll need a production directive here about how to format the
+      table.
+    </remark>
+
     <informaltable>
       <tgroup cols="4">
         <colspec colwidth="15*"/>
@@ -1908,10 +1908,10 @@
     </para>
 
     <para>
-      The display width does not constrain the range of values that can
-      be stored in the column, nor the number of digits that are
-      displayed for values having a width exceeding that specified for
-      the column.
+      The display width does <emphasis>not</emphasis> constrain the
+      range of values that can be stored in the column, nor the number
+      of digits that are displayed for values having a width exceeding
+      that specified for the column.
     </para>
 
     <para>
@@ -1923,7 +1923,7 @@
       Note that if you store larger values than the display width in an
       integer column, you may experience problems when MySQL generates
       temporary tables for some complicated joins, because in these
-      cases MySQL trusts that the data did fit into the original column
+      cases MySQL assumes that the data fits into the original column
       width.
     </para>
 
@@ -1931,7 +1931,12 @@
       All integer types can have an optional (non-standard) attribute
       <literal>UNSIGNED</literal>. Unsigned values can be used when you
       want to allow only non-negative numbers in a column and you need a
-      larger upper numeric range for the column.
+      larger upper numeric range for the column. For example, if an
+      <literal>INT</literal> column is <literal>UNSIGNED</literal>, the
+      size of the column's range is the same but its endpoints shift
+      from <literal>-2147483648</literal> and
+      <literal>2147483647</literal> up to <literal>0</literal> and
+      <literal>4294967295</literal>.
     </para>
 
     <para>
@@ -1955,15 +1960,16 @@
     </para>
 
     <para>
-      The <literal>FLOAT</literal> type is used to represent approximate
-      numeric data types. The SQL standard allows an optional
+      The <literal>FLOAT</literal> and <literal>DOUBLE</literal> data
+      types are used to represent approximate numeric data values. For
+      <literal>FLOAT</literal> the SQL standard allows an optional
       specification of the precision (but not the range of the exponent)
       in bits following the keyword <literal>FLOAT</literal> in
-      parentheses. The MySQL implementation also supports this optional
-      precision specification, but the precision value is used only to
-      determine storage size. A precision from 0 to 23 results in a
-      four-byte single-precision <literal>FLOAT</literal> column. A
-      precision from 24 to 53 results in an eight-byte double-precision
+      parentheses. MySQL also supports this optional precision
+      specification, but the precision value is used only to determine
+      storage size. A precision from 0 to 23 results in a four-byte
+      single-precision <literal>FLOAT</literal> column. A precision from
+      24 to 53 results in an eight-byte double-precision
       <literal>DOUBLE</literal> column.
     </para>
 
@@ -2003,14 +2009,26 @@
     </para>
 
     <para>
-      The <literal>DECIMAL</literal> and <literal>NUMERIC</literal>
-      types are implemented as the same type by MySQL. They are used to
-      store values for which it is important to preserve exact
-      precision, for example with monetary data. When declaring a column
-      of one of these types, the precision and scale can be (and usually
-      is) specified; for example:
+      The <literal>DECIMAL</literal> and <literal>NUMERIC</literal> data
+      types are used to store exact numeric data values. In MySQL,
+      <literal>NUMERIC</literal> is implemented as
+      <literal>DECIMAL</literal>. These types are used to store values
+      for which it is important to preserve exact precision, for example
+      with monetary data.
     </para>
 
+    <para>
+      MySQL &current-series; stores <literal>DECIMAL</literal> and
+      <literal>NUMERIC</literal> values in binary format. Previously,
+      they were stored as strings. See <xref linkend="precision-math"/>.
+    </para>
+
+    <para>
+      When declaring a <literal>DECIMAL</literal> or
+      <literal>NUMERIC</literal> column, the precision and scale can be
+      (and usually is) specified; for example:
+    </para>
+
 <programlisting>
 salary DECIMAL(5,2)
 </programlisting>
@@ -2020,15 +2038,12 @@
       <literal>2</literal> is the scale. The precision represents the
       number of significant digits that are stored for values, and the
       scale represents the number of digits that can be stored following
-      the decimal point.
+      the decimal point. If the scale is 0, <literal>DECIMAL</literal>
+      and <literal>NUMERIC</literal> values contain no decimal point or
+      fractional part.
     </para>
 
     <para>
-      MySQL &current-series; stores <literal>DECIMAL</literal> and
-      <literal>NUMERIC</literal> values in binary format.
-    </para>
-
-    <para>
       Standard SQL requires that the <literal>salary</literal> column be
       able to store any value with five digits and two decimals. In this
       case, therefore, the range of values that can be stored in the
@@ -2044,10 +2059,10 @@
       Similarly, the syntax <literal>DECIMAL</literal> is equivalent to
       <literal>DECIMAL(<replaceable>M</replaceable>,0)</literal>, where
       the implementation is allowed to decide the value of
-      <replaceable>M</replaceable>. Both of these variant forms of the
-      <literal>DECIMAL</literal> and <literal>NUMERIC</literal> data
-      types are supported in MySQL &current-series;. The default value
-      of <replaceable>M</replaceable> is 10.
+      <replaceable>M</replaceable>. MySQL supports both of these variant
+      forms of the <literal>DECIMAL</literal> and
+      <literal>NUMERIC</literal> syntax. The default value of
+      <replaceable>M</replaceable> is 10.
     </para>
 
     <para>
@@ -2063,8 +2078,8 @@
     </para>
 
     <para>
-      The <literal>BIT</literal> data type can be used to store
-      bit-field values. A type of
+      The <literal>BIT</literal> data type is used to store bit-field
+      values. A type of
       <literal>BIT(<replaceable>M</replaceable>)</literal> allows for
       storage of <replaceable>M</replaceable>-bit values.
       <replaceable>M</replaceable> can range from 1 to 64.
@@ -2092,50 +2107,24 @@
     <para>
       When asked to store a value in a numeric column that is outside
       the data type's allowable range, MySQL's behavior depends on the
-      SQL mode in effect at the time. If the mode is not set, MySQL
-      clips the value to the appropriate endpoint of the range and
-      stores the resulting value instead. However, if the mode is set to
-      <literal>traditional</literal> (<quote>strict mode</quote>), a
-      value that is out of range is rejected with an error, and the
-      insert fails, in accordance with the SQL standard. See
-      <xref
-        linkend="server-sql-mode"/>.
+      SQL mode in effect at the time. For example, if no restrictive
+      modes are enabled, MySQL clips the value to the appropriate
+      endpoint of the range and stores the resulting value instead.
+      However, if the mode is set to <literal>TRADITIONAL</literal>,
+      MySQL rejects a value that is out of range with an error, and the
+      insert fails, in accordance with the SQL standard.
     </para>
 
-    <remark role="todo">
-      [js] Add new example(s) once Bug#11546 is (really) fixed.
-      Grrrrrrrr...!
-    </remark>
-
-<!--
     <para>
-      For example, the range of an <literal>INT</literal> column is
-      <literal>-2147483648</literal> to <literal>2147483647</literal>.
-      If you try to insert <literal>-9999999999</literal> into an
-      <literal>INT</literal> column, MySQL clips the value to the lower
-      endpoint of the range and stores <literal>-2147483648</literal>
-      instead. Similarly, if you try to insert
-      <literal>9999999999</literal>, MySQL clips the value to the upper
-      endpoint of the range and stores <literal>2147483647</literal>
-      instead. If you set ...
-    </para>
--->
-
-    <para>
-      If the <literal>INT</literal> column is
-      <literal>UNSIGNED</literal>, the size of the column's range is the
-      same but its endpoints shift up to <literal>0</literal> and
-      <literal>4294967295</literal>. If you try to store
-      <literal>-9999999999</literal> and <literal>9999999999</literal>,
-      the values stored in the column are <literal>0</literal> and
-      <literal>4294967296</literal> in non-strict mode.
-    </para>
-
-    <para>
+      In non-strict mode, when an out-of-range value is assigned to an
+      integer column, MySQL stores the value representing the
+      corresponding endpoint of the column data type range. If you store
+      256 into a <literal>TINYINT</literal> or <literal>TINYINT
+      UNSIGNED</literal> column, MySQL stores 255 or 127, respectively.
       When a floating-point or fixed-point column is assigned a value
       that exceeds the range implied by the specified (or default)
-      precision and scale, MySQL in non-strict mode stores the value
-      representing the corresponding end point of that range.
+      precision and scale, MySQL stores the value representing the
+      corresponding endpoint of that range.
     </para>
 
     <para>
@@ -2146,8 +2135,8 @@
       <literal>INSERT</literal> statements. When MySQL is operating in
       strict mode, these statements fail, and some or all of the values
       will not be inserted or changed, depending on whether the table is
-      a transactional table and other factors. See
-      <xref linkend="server-sql-mode"/>, for details.
+      a transactional table and other factors. For details, see
+      <xref linkend="server-sql-mode"/>.
     </para>
 
   </section>
@@ -2179,16 +2168,18 @@
 
     <para>
       MySQL gives warnings or errors if you try to insert an illegal
-      date. You can get MySQL to accept certain dates, such as
-      <literal>'1999-11-31'</literal>, by using the
-      <literal>ALLOW_INVALID_DATES</literal> SQL mode. This is useful
-      when you want to store a <quote>possibly wrong</quote> value which
-      the user has specified (for example, in a web form) in the
-      database for future processing. Under this mode, MySQL verifies
-      only that the month is in the range from 0 to 12 and that the day
-      is in the range from 0 to 31. These ranges are defined to include
-      zero because MySQL allows you to store dates where the day or
-      month and day are zero in a <literal>DATE</literal> or
+      date. By setting the SQL mode to the appropriate value, you can
+      specify more exactly what kind of dates you want MySQL to support.
+      (See <xref linkend="server-sql-mode"/>.) You can get MySQL to
+      accept certain dates, such as <literal>'1999-11-31'</literal>, by
+      using the <literal>ALLOW_INVALID_DATES</literal> SQL mode. This is
+      useful when you want to store a <quote>possibly wrong</quote>
+      value which the user has specified (for example, in a web form) in
+      the database for future processing. Under this mode, MySQL
+      verifies only that the month is in the range from 0 to 12 and that
+      the day is in the range from 0 to 31. These ranges are defined to
+      include zero because MySQL allows you to store dates where the day
+      or month and day are zero in a <literal>DATE</literal> or
       <literal>DATETIME</literal> column. This is extremely useful for
       applications that need to store a birthdate for which you do not
       know the exact date. In this case, you simply store the date as
@@ -2210,12 +2201,6 @@
     </para>
 
     <para>
-      By setting the <literal>sql_mode</literal> system variable to the
-      appropriate mode values, You can more exactly what kind of dates
-      you want MySQL to support. See <xref linkend="server-sql-mode"/>.
-    </para>
-
-    <para>
       Here are some general considerations to keep in mind when working
       with date and time types:
     </para>
@@ -2282,13 +2267,13 @@
 
       <listitem>
         <para>
-          When MySQL encounters a value for a date or time type that is
-          out of range or otherwise illegal for the type (as described
-          at the beginning of this section), it converts the value to
-          the <quote>zero</quote> value for that type. The exception is
-          that out-of-range <literal>TIME</literal> values are clipped
-          to the appropriate endpoint of the <literal>TIME</literal>
-          range.
+          By default, when MySQL encounters a value for a date or time
+          type that is out of range or otherwise illegal for the type
+          (as described at the beginning of this section), it converts
+          the value to the <quote>zero</quote> value for that type. The
+          exception is that out-of-range <literal>TIME</literal> values
+          are clipped to the appropriate endpoint of the
+          <literal>TIME</literal> range.
         </para>
 
         <para>
@@ -3633,7 +3618,7 @@
         <literal>VARCHAR</literal>, except that they contain binary
         strings rather than non-binary strings. That is, they contain
         byte strings rather than character strings. This means that they
-        have no character set, and sorting and comparison is based on
+        have no character set, and sorting and comparison are based on
         the numeric values of the bytes in column values.
       </para>
 

Modified: trunk/refman-5.1/spatial-extensions.xml
===================================================================
--- trunk/refman-5.1/spatial-extensions.xml	2006-01-18 21:11:29 UTC (rev 907)
+++ trunk/refman-5.1/spatial-extensions.xml	2006-01-18 21:11:43 UTC (rev 908)
@@ -751,7 +751,7 @@
         <listitem>
           <para>
             A <literal>Curve</literal> is closed if its start point is
-            equal to its end point.
+            equal to its endpoint.
           </para>
         </listitem>
 
@@ -764,7 +764,7 @@
         <listitem>
           <para>
             The boundary of a non-closed <literal>Curve</literal>
-            consists of its two end points.
+            consists of its two endpoints.
           </para>
         </listitem>
 
@@ -3433,7 +3433,7 @@
             </para>
 
             <para>
-              Returns the <literal>Point</literal> that is the end point
+              Returns the <literal>Point</literal> that is the endpoint
               of the <literal>LineString</literal> value
               <replaceable>ls</replaceable>.
             </para>

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