List:Commits« Previous MessageNext Message »
From:paul.dubois Date:October 15 2010 4:21pm
Subject:svn commit - mysqldoc@docsrva: r23159 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-5.5 refman-5.6 refman-6.0
View as plain text  
Author: paul
Date: 2010-10-15 18:21:16 +0200 (Fri, 15 Oct 2010)
New Revision: 23159

Log:
 r64250@frost:  paul | 2010-10-15 11:17:51 -0500
 Precision-math and data-type revisions


Modified:
   trunk/refman-4.1/functions-core.xml
   trunk/refman-5.0/data-types.xml
   trunk/refman-5.0/functions-core.xml
   trunk/refman-5.0/precision-math.xml
   trunk/refman-5.1/data-types.xml
   trunk/refman-5.1/functions-core.xml
   trunk/refman-5.1/precision-math.xml
   trunk/refman-5.5/data-types.xml
   trunk/refman-5.5/functions-core.xml
   trunk/refman-5.5/precision-math.xml
   trunk/refman-5.6/data-types.xml
   trunk/refman-5.6/functions-core.xml
   trunk/refman-5.6/precision-math.xml
   trunk/refman-6.0/data-types.xml
   trunk/refman-6.0/functions-core.xml
   trunk/refman-6.0/precision-math.xml

Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - 07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/mysqldoc/trunk:35498
07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/trunk:43228
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:43968
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/trunk:44480
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:64242
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:39036
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/trunk:39546
   + 07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/mysqldoc/trunk:35498
07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/trunk:43228
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:43968
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/trunk:44480
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:64250
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:39036
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/trunk:39546


Modified: trunk/refman-4.1/functions-core.xml
===================================================================
--- trunk/refman-4.1/functions-core.xml	2010-10-15 15:15:18 UTC (rev 23158)
+++ trunk/refman-4.1/functions-core.xml	2010-10-15 16:21:16 UTC (rev 23159)
Changed blocks: 2, Lines Added: 5, Lines Deleted: 6; 1230 bytes

@@ -5641,12 +5641,11 @@
 
         <listitem>
           <para>
-            If one of the operands is an unsigned integer, and the other
-            operand is also an integer, the result is an unsigned
-            integer. For subtraction, if the
+            If both operands are integers and any of them are unsigned,
+            the result is an unsigned integer. For subtraction, if the
             <literal role="sqlmode">NO_UNSIGNED_SUBTRACTION</literal>
-            SQL mode is enabled, the subtraction result is signed even
-            if any operand is unsigned.
+            SQL mode is enabled, the result is signed even if any
+            operand is unsigned.
           </para>
         </listitem>
 

@@ -5683,7 +5682,7 @@
 
       <para>
         For information about handling of overflow in numeric expression
-        evaluation, see <xref linkend="numeric-types"/>.
+        evaluation, see <xref linkend="out-of-range-and-overflow"/>.
       </para>
 
       <para>


Modified: trunk/refman-5.0/data-types.xml
===================================================================
--- trunk/refman-5.0/data-types.xml	2010-10-15 15:15:18 UTC (rev 23158)
+++ trunk/refman-5.0/data-types.xml	2010-10-15 16:21:16 UTC (rev 23159)
Changed blocks: 1, Lines Added: 4, Lines Deleted: 4; 1168 bytes

@@ -2370,10 +2370,10 @@
       <literal role="type">REAL</literal>, and
       <literal role="type">DOUBLE PRECISION</literal>). The keyword
       <literal role="type">INT</literal> is a synonym for
-      <literal role="type">INTEGER</literal>, and the keyword
-      <literal role="type">DEC</literal> is a synonym for
-      <literal role="type">DECIMAL</literal>. MySQL treats
-      <literal role="type">DOUBLE</literal> as a synonym for
+      <literal role="type">INTEGER</literal>, and the keywords
+      <literal role="type">DEC</literal> and <literal>FIXED</literal>
+      are synonyms for <literal role="type">DECIMAL</literal>. MySQL
+      treats <literal role="type">DOUBLE</literal> as a synonym for
       <literal role="type">DOUBLE PRECISION</literal> (a nonstandard
       extension). MySQL also treats <literal role="type">REAL</literal>
       as a synonym for <literal role="type">DOUBLE PRECISION</literal>


Modified: trunk/refman-5.0/functions-core.xml
===================================================================
--- trunk/refman-5.0/functions-core.xml	2010-10-15 15:15:18 UTC (rev 23158)
+++ trunk/refman-5.0/functions-core.xml	2010-10-15 16:21:16 UTC (rev 23159)
Changed blocks: 2, Lines Added: 5, Lines Deleted: 6; 1230 bytes

@@ -5778,12 +5778,11 @@
 
         <listitem>
           <para>
-            If one of the operands is an unsigned integer, and the other
-            operand is also an integer, the result is an unsigned
-            integer. For subtraction, if the
+            If both operands are integers and any of them are unsigned,
+            the result is an unsigned integer. For subtraction, if the
             <literal role="sqlmode">NO_UNSIGNED_SUBTRACTION</literal>
-            SQL mode is enabled, the subtraction result is signed even
-            if any operand is unsigned.
+            SQL mode is enabled, the result is signed even if any
+            operand is unsigned.
           </para>
         </listitem>
 

@@ -5834,7 +5833,7 @@
 
       <para>
         For information about handling of overflow in numeric expression
-        evaluation, see <xref linkend="numeric-types"/>.
+        evaluation, see <xref linkend="out-of-range-and-overflow"/>.
       </para>
 
       <para>


Modified: trunk/refman-5.0/precision-math.xml
===================================================================
--- trunk/refman-5.0/precision-math.xml	2010-10-15 15:15:18 UTC (rev 23158)
+++ trunk/refman-5.0/precision-math.xml	2010-10-15 16:21:16 UTC (rev 23159)
Changed blocks: 11, Lines Added: 38, Lines Deleted: 65; 8677 bytes

@@ -84,20 +84,22 @@
   </itemizedlist>
 
   <para>
-    These changes have several implications for numeric operations:
+    These changes result in the following characteristics for numeric
+    operations and provide improved compliance with standard SQL:
   </para>
 
   <itemizedlist>
 
     <listitem>
       <para>
-        <emphasis role="bold">More precise calculations</emphasis>: For
+        <emphasis role="bold">Precise calculations</emphasis>: For
         exact-value numbers, calculations do not introduce
         floating-point errors. Instead, exact precision is used. For
-        example, a number such as <literal>.0001</literal> is treated as
-        an exact value rather than as an approximation, and summing it
-        10,000 times produces a result of exactly <literal>1</literal>,
-        not a value that merely <quote>close</quote> to 1.
+        example, MySQL treats a number such as <literal>.0001</literal>
+        as an exact value rather than as an approximation, and summing
+        it 10,000 times produces a result of exactly
+        <literal>1</literal>, not a value that is merely
+        <quote>close</quote> to 1.
       </para>
     </listitem>
 

@@ -113,7 +115,7 @@
 
     <listitem>
       <para>
-        <emphasis role="bold">Improved platform independence</emphasis>:
+        <emphasis role="bold">Platform independence</emphasis>:
         Operations on exact numeric values are the same across different
         platforms such as Windows and Unix.
       </para>

@@ -129,26 +131,19 @@
         type. Similarly, you can treat division by zero as an error
         rather than as an operation that produces a result of
         <literal>NULL</literal>. The choice of which approach to take is
-        determined by the setting of the
-        <literal role="sysvar">sql_mode</literal> system variable.
+        determined by the setting of the server SQL mode.
       </para>
     </listitem>
 
   </itemizedlist>
 
   <para>
-    An important result of these changes is that MySQL provides improved
-    compliance with standard SQL.
-  </para>
-
-  <para>
     The following discussion covers several aspects of how precision
-    math works (including possible incompatibilities with older
-    applications). At the end, some examples are given that demonstrate
+    math works, including possible incompatibilities with older
+    applications. At the end, some examples are given that demonstrate
     how MySQL &current-series; handles numeric operations precisely. For
-    information about using the
-    <literal role="sysvar">sql_mode</literal> system variable to control
-    the SQL mode, see <xref linkend="server-sql-mode"/>.
+    information about controlling the SQL mode, see
+    <xref linkend="server-sql-mode"/>.
   </para>
 
   <section id="precision-math-numbers">

@@ -159,8 +154,8 @@
       The scope of precision math for exact-value operations includes
       the exact-value data types (<literal role="type">DECIMAL</literal>
       and integer types) and exact-value numeric literals.
-      Approximate-value data types and numeric literals still are
-      handled as floating-point numbers.
+      Approximate-value data types and numeric literals are handled as
+      floating-point numbers.
     </para>
 
     <para>

@@ -180,11 +175,10 @@
     </para>
 
     <para>
-      Two numbers that look similar need not be both exact-value or both
-      approximate-value. For example, <literal>2.34</literal> is an
-      exact-value (fixed-point) number, whereas
-      <literal>2.34E0</literal> is an approximate-value (floating-point)
-      number.
+      Two numbers that look similar may be treated differently. For
+      example, <literal>2.34</literal> is an exact-value (fixed-point)
+      number, whereas <literal>2.34E0</literal> is an approximate-value
+      (floating-point) number.
     </para>
 
     <para>

@@ -251,9 +245,9 @@
     </itemizedlist>
 
     <para>
-      Some of these changes result in possible incompatibilities for
-      applications that are written for older versions of MySQL. These
-      incompatibilities are noted throughout this section.
+      Some of these characteristics result in possible incompatibilities
+      for applications that are written for older versions of MySQL.
+      These incompatibilities are noted throughout this section.
     </para>
 
     <para>

@@ -292,7 +286,7 @@
       that calculations on <literal role="type">DECIMAL</literal> values
       are accurate up to 65 digits. This limit of 65 digits of precision
       also applies to exact-value numeric literals, so the maximum range
-      of such literals is different from before. (Prior to MySQL 5.0.3,
+      of such literals differs from before. (Prior to MySQL 5.0.3,
       decimal values could have up to 254 digits. However, calculations
       were done using floating-point and thus were approximate, not
       exact.) This change in the range of literal values is another

@@ -301,16 +295,15 @@
 
     <para>
       Values for <literal role="type">DECIMAL</literal> columns no
-      longer are represented as strings that require one byte per digit
-      or sign character. Instead, a binary format is used that packs
-      nine decimal digits into four bytes. This change to
+      longer are represented as strings that require 1 byte per digit or
+      sign character. Instead, a binary format is used that packs nine
+      decimal digits into 4 bytes. This change to
       <literal role="type">DECIMAL</literal> storage format changes the
       storage requirements as well. The storage requirements for the
       integer and fractional parts of each value are determined
-      separately. Each multiple of nine digits requires four bytes, and
-      any remaining digits left over require some fraction of four
-      bytes. The storage required for remaining digits is given by the
-      following table.
+      separately. Each multiple of nine digits requires 4 bytes, and any
+      remaining digits require some fraction of 4 bytes. The storage
+      required for remaining digits is given by the following table.
     </para>
 
     <informaltable>

@@ -327,41 +320,21 @@
             <entry>0</entry>
           </row>
           <row>
+            <entry>1&ndash;2</entry>
             <entry>1</entry>
-            <entry>1</entry>
           </row>
           <row>
+            <entry>3&ndash;4</entry>
             <entry>2</entry>
-            <entry>1</entry>
           </row>
           <row>
+            <entry>5&ndash;6</entry>
             <entry>3</entry>
-            <entry>2</entry>
           </row>
           <row>
+            <entry>7&ndash;9</entry>
             <entry>4</entry>
-            <entry>2</entry>
           </row>
-          <row>
-            <entry>5</entry>
-            <entry>3</entry>
-          </row>
-          <row>
-            <entry>6</entry>
-            <entry>3</entry>
-          </row>
-          <row>
-            <entry>7</entry>
-            <entry>4</entry>
-          </row>
-          <row>
-            <entry>8</entry>
-            <entry>4</entry>
-          </row>
-          <row>
-            <entry>9</entry>
-            <entry>4</entry>
-          </row>
         </tbody>
       </tgroup>
     </informaltable>

@@ -369,11 +342,11 @@
     <para>
       For example, a <literal>DECIMAL(18,9)</literal> column has nine
       digits on either side of the decimal point, so the integer part
-      and the fractional part each require four bytes. A
+      and the fractional part each require 4 bytes. A
       <literal>DECIMAL(20,6)</literal> column has fourteen integer
       digits and six fractional digits. The integer digits require four
-      bytes for nine of the digits and three bytes for the remaining
-      five digits. The six fractional digits require three bytes.
+      bytes for nine of the digits and 3 bytes for the remaining five
+      digits. The six fractional digits require 3 bytes.
     </para>
 
     <para>

@@ -395,7 +368,7 @@
       The change of storage format also means that
       <literal role="type">DECIMAL</literal> columns no longer support
       the nonstandard extension that permitted values larger than the
-      range implied by the column definition. Formerly, one byte was
+      range implied by the column definition. Formerly, 1 byte was
       allocated for storing the sign character. For positive values that
       needed no sign byte, MySQL permitted an extra digit to be stored
       instead. For example, a <literal>DECIMAL(3,0)</literal> column


Modified: trunk/refman-5.1/data-types.xml
===================================================================
--- trunk/refman-5.1/data-types.xml	2010-10-15 15:15:18 UTC (rev 23158)
+++ trunk/refman-5.1/data-types.xml	2010-10-15 16:21:16 UTC (rev 23159)
Changed blocks: 1, Lines Added: 4, Lines Deleted: 4; 1168 bytes

@@ -2231,10 +2231,10 @@
       <literal role="type">REAL</literal>, and
       <literal role="type">DOUBLE PRECISION</literal>). The keyword
       <literal role="type">INT</literal> is a synonym for
-      <literal role="type">INTEGER</literal>, and the keyword
-      <literal role="type">DEC</literal> is a synonym for
-      <literal role="type">DECIMAL</literal>. MySQL treats
-      <literal role="type">DOUBLE</literal> as a synonym for
+      <literal role="type">INTEGER</literal>, and the keywords
+      <literal role="type">DEC</literal> and <literal>FIXED</literal>
+      are synonyms for <literal role="type">DECIMAL</literal>. MySQL
+      treats <literal role="type">DOUBLE</literal> as a synonym for
       <literal role="type">DOUBLE PRECISION</literal> (a nonstandard
       extension). MySQL also treats <literal role="type">REAL</literal>
       as a synonym for <literal role="type">DOUBLE PRECISION</literal>


Modified: trunk/refman-5.1/functions-core.xml
===================================================================
--- trunk/refman-5.1/functions-core.xml	2010-10-15 15:15:18 UTC (rev 23158)
+++ trunk/refman-5.1/functions-core.xml	2010-10-15 16:21:16 UTC (rev 23159)
Changed blocks: 2, Lines Added: 5, Lines Deleted: 6; 1230 bytes

@@ -5707,12 +5707,11 @@
 
         <listitem>
           <para>
-            If one of the operands is an unsigned integer, and the other
-            operand is also an integer, the result is an unsigned
-            integer. For subtraction, if the
+            If both operands are integers and any of them are unsigned,
+            the result is an unsigned integer. For subtraction, if the
             <literal role="sqlmode">NO_UNSIGNED_SUBTRACTION</literal>
-            SQL mode is enabled, the subtraction result is signed even
-            if any operand is unsigned.
+            SQL mode is enabled, the result is signed even if any
+            operand is unsigned.
           </para>
         </listitem>
 

@@ -5763,7 +5762,7 @@
 
       <para>
         For information about handling of overflow in numeric expression
-        evaluation, see <xref linkend="numeric-types"/>.
+        evaluation, see <xref linkend="out-of-range-and-overflow"/>.
       </para>
 
       <para>


Modified: trunk/refman-5.1/precision-math.xml
===================================================================
--- trunk/refman-5.1/precision-math.xml	2010-10-15 15:15:18 UTC (rev 23158)
+++ trunk/refman-5.1/precision-math.xml	2010-10-15 16:21:16 UTC (rev 23159)
Changed blocks: 8, Lines Added: 34, Lines Deleted: 60; 7062 bytes

@@ -83,7 +83,8 @@
   </itemizedlist>
 
   <para>
-    These features have several implications for numeric operations:
+    These features have several implications for numeric operations and
+    provide a high degree of compliance with standard SQL:
   </para>
 
   <itemizedlist>

@@ -93,10 +94,11 @@
         <emphasis role="bold">Precise calculations</emphasis>: For
         exact-value numbers, calculations do not introduce
         floating-point errors. Instead, exact precision is used. For
-        example, a number such as <literal>.0001</literal> is treated as
-        an exact value rather than as an approximation, and summing it
-        10,000 times produces a result of exactly <literal>1</literal>,
-        not a value that merely <quote>close</quote> to 1.
+        example, MySQL treats a number such as <literal>.0001</literal>
+        as an exact value rather than as an approximation, and summing
+        it 10,000 times produces a result of exactly
+        <literal>1</literal>, not a value that is merely
+        <quote>close</quote> to 1.
       </para>
     </listitem>
 

@@ -128,26 +130,19 @@
         type. Similarly, you can treat division by zero as an error
         rather than as an operation that produces a result of
         <literal>NULL</literal>. The choice of which approach to take is
-        determined by the setting of the
-        <literal role="sysvar">sql_mode</literal> system variable.
+        determined by the setting of the server SQL mode.
       </para>
     </listitem>
 
   </itemizedlist>
 
   <para>
-    An important result of these features is that MySQL &current-series;
-    provides a high degree of compliance with standard SQL.
-  </para>
-
-  <para>
     The following discussion covers several aspects of how precision
-    math works (including possible incompatibilities with older
-    applications). At the end, some examples are given that demonstrate
+    math works, including possible incompatibilities with older
+    applications. At the end, some examples are given that demonstrate
     how MySQL &current-series; handles numeric operations precisely. For
-    information about using the
-    <literal role="sysvar">sql_mode</literal> system variable to control
-    the SQL mode, see <xref linkend="server-sql-mode"/>.
+    information about controlling the SQL mode, see
+    <xref linkend="server-sql-mode"/>.
   </para>
 
   <section id="precision-math-numbers">

@@ -158,8 +153,8 @@
       The scope of precision math for exact-value operations includes
       the exact-value data types (<literal role="type">DECIMAL</literal>
       and integer types) and exact-value numeric literals.
-      Approximate-value data types and numeric literals still are
-      handled as floating-point numbers.
+      Approximate-value data types and numeric literals are handled as
+      floating-point numbers.
     </para>
 
     <para>

@@ -179,11 +174,10 @@
     </para>
 
     <para>
-      Two numbers that look similar need not be both exact-value or both
-      approximate-value. For example, <literal>2.34</literal> is an
-      exact-value (fixed-point) number, whereas
-      <literal>2.34E0</literal> is an approximate-value (floating-point)
-      number.
+      Two numbers that look similar may be treated differently. For
+      example, <literal>2.34</literal> is an exact-value (fixed-point)
+      number, whereas <literal>2.34E0</literal> is an approximate-value
+      (floating-point) number.
     </para>
 
     <para>

@@ -287,21 +281,21 @@
       that calculations on <literal role="type">DECIMAL</literal> values
       are accurate up to 65 digits. This limit of 65 digits of precision
       also applies to exact-value numeric literals, so the maximum range
-      of such literals is different from before. (In older versions of
-      MySQL, decimal values could have up to 254 digits. However,
-      calculations were done using floating-point and thus were
-      approximate, not exact.)
+      of such literals differs from before. (In older versions of MySQL,
+      decimal values could have up to 254 digits. However, calculations
+      were done using floating-point and thus were approximate, not
+      exact.)
     </para>
 
     <para>
       Values for <literal role="type">DECIMAL</literal> columns in MySQL
       &current-series; are stored using a binary format that packs nine
-      decimal digits into four bytes. The storage requirements for the
+      decimal digits into 4 bytes. The storage requirements for the
       integer and fractional parts of each value are determined
-      separately. Each multiple of nine digits requires four bytes, and
-      any remaining digits left over require some fraction of four
-      bytes. The storage required for remaining digits is given by the
-      following table.
+      separately. Each multiple of nine digits requires 4 bytes, and any
+      remaining digits left over require some fraction of 4 bytes. The
+      storage required for remaining digits is given by the following
+      table.
     </para>
 
     <informaltable>

@@ -318,41 +312,21 @@
             <entry>0</entry>
           </row>
           <row>
+            <entry>1&ndash;2</entry>
             <entry>1</entry>
-            <entry>1</entry>
           </row>
           <row>
+            <entry>3&ndash;4</entry>
             <entry>2</entry>
-            <entry>1</entry>
           </row>
           <row>
+            <entry>5&ndash;6</entry>
             <entry>3</entry>
-            <entry>2</entry>
           </row>
           <row>
+            <entry>7&ndash;9</entry>
             <entry>4</entry>
-            <entry>2</entry>
           </row>
-          <row>
-            <entry>5</entry>
-            <entry>3</entry>
-          </row>
-          <row>
-            <entry>6</entry>
-            <entry>3</entry>
-          </row>
-          <row>
-            <entry>7</entry>
-            <entry>4</entry>
-          </row>
-          <row>
-            <entry>8</entry>
-            <entry>4</entry>
-          </row>
-          <row>
-            <entry>9</entry>
-            <entry>4</entry>
-          </row>
         </tbody>
       </tgroup>
     </informaltable>

@@ -360,11 +334,11 @@
     <para>
       For example, a <literal>DECIMAL(18,9)</literal> column has nine
       digits on either side of the decimal point, so the integer part
-      and the fractional part each require four bytes. A
+      and the fractional part each require 4 bytes. A
       <literal>DECIMAL(20,6)</literal> column has fourteen integer
       digits and six fractional digits. The integer digits require four
-      bytes for nine of the digits and three bytes for the remaining
-      five digits. The six fractional digits require three bytes.
+      bytes for nine of the digits and 3 bytes for the remaining five
+      digits. The six fractional digits require 3 bytes.
     </para>
 
     <para>


Modified: trunk/refman-5.5/data-types.xml
===================================================================
--- trunk/refman-5.5/data-types.xml	2010-10-15 15:15:18 UTC (rev 23158)
+++ trunk/refman-5.5/data-types.xml	2010-10-15 16:21:16 UTC (rev 23159)
Changed blocks: 1, Lines Added: 4, Lines Deleted: 4; 1168 bytes

@@ -2231,10 +2231,10 @@
       <literal role="type">REAL</literal>, and
       <literal role="type">DOUBLE PRECISION</literal>). The keyword
       <literal role="type">INT</literal> is a synonym for
-      <literal role="type">INTEGER</literal>, and the keyword
-      <literal role="type">DEC</literal> is a synonym for
-      <literal role="type">DECIMAL</literal>. MySQL treats
-      <literal role="type">DOUBLE</literal> as a synonym for
+      <literal role="type">INTEGER</literal>, and the keywords
+      <literal role="type">DEC</literal> and <literal>FIXED</literal>
+      are synonyms for <literal role="type">DECIMAL</literal>. MySQL
+      treats <literal role="type">DOUBLE</literal> as a synonym for
       <literal role="type">DOUBLE PRECISION</literal> (a nonstandard
       extension). MySQL also treats <literal role="type">REAL</literal>
       as a synonym for <literal role="type">DOUBLE PRECISION</literal>


Modified: trunk/refman-5.5/functions-core.xml
===================================================================
--- trunk/refman-5.5/functions-core.xml	2010-10-15 15:15:18 UTC (rev 23158)
+++ trunk/refman-5.5/functions-core.xml	2010-10-15 16:21:16 UTC (rev 23159)
Changed blocks: 2, Lines Added: 5, Lines Deleted: 6; 1230 bytes

@@ -5889,12 +5889,11 @@
 
         <listitem>
           <para>
-            If one of the operands is an unsigned integer, and the other
-            operand is also an integer, the result is an unsigned
-            integer. For subtraction, if the
+            If both operands are integers and any of them are unsigned,
+            the result is an unsigned integer. For subtraction, if the
             <literal role="sqlmode">NO_UNSIGNED_SUBTRACTION</literal>
-            SQL mode is enabled, the subtraction result is signed even
-            if any operand is unsigned.
+            SQL mode is enabled, the result is signed even if any
+            operand is unsigned.
           </para>
         </listitem>
 

@@ -5945,7 +5944,7 @@
 
       <para>
         For information about handling of overflow in numeric expression
-        evaluation, see <xref linkend="numeric-types"/>.
+        evaluation, see <xref linkend="out-of-range-and-overflow"/>.
       </para>
 
       <para>


Modified: trunk/refman-5.5/precision-math.xml
===================================================================
--- trunk/refman-5.5/precision-math.xml	2010-10-15 15:15:18 UTC (rev 23158)
+++ trunk/refman-5.5/precision-math.xml	2010-10-15 16:21:16 UTC (rev 23159)
Changed blocks: 8, Lines Added: 34, Lines Deleted: 60; 7062 bytes

@@ -83,7 +83,8 @@
   </itemizedlist>
 
   <para>
-    These features have several implications for numeric operations:
+    These features have several implications for numeric operations and
+    provide a high degree of compliance with standard SQL:
   </para>
 
   <itemizedlist>

@@ -93,10 +94,11 @@
         <emphasis role="bold">Precise calculations</emphasis>: For
         exact-value numbers, calculations do not introduce
         floating-point errors. Instead, exact precision is used. For
-        example, a number such as <literal>.0001</literal> is treated as
-        an exact value rather than as an approximation, and summing it
-        10,000 times produces a result of exactly <literal>1</literal>,
-        not a value that merely <quote>close</quote> to 1.
+        example, MySQL treats a number such as <literal>.0001</literal>
+        as an exact value rather than as an approximation, and summing
+        it 10,000 times produces a result of exactly
+        <literal>1</literal>, not a value that is merely
+        <quote>close</quote> to 1.
       </para>
     </listitem>
 

@@ -128,26 +130,19 @@
         type. Similarly, you can treat division by zero as an error
         rather than as an operation that produces a result of
         <literal>NULL</literal>. The choice of which approach to take is
-        determined by the setting of the
-        <literal role="sysvar">sql_mode</literal> system variable.
+        determined by the setting of the server SQL mode.
       </para>
     </listitem>
 
   </itemizedlist>
 
   <para>
-    An important result of these features is that MySQL &current-series;
-    provides a high degree of compliance with standard SQL.
-  </para>
-
-  <para>
     The following discussion covers several aspects of how precision
-    math works (including possible incompatibilities with older
-    applications). At the end, some examples are given that demonstrate
+    math works, including possible incompatibilities with older
+    applications. At the end, some examples are given that demonstrate
     how MySQL &current-series; handles numeric operations precisely. For
-    information about using the
-    <literal role="sysvar">sql_mode</literal> system variable to control
-    the SQL mode, see <xref linkend="server-sql-mode"/>.
+    information about controlling the SQL mode, see
+    <xref linkend="server-sql-mode"/>.
   </para>
 
   <section id="precision-math-numbers">

@@ -158,8 +153,8 @@
       The scope of precision math for exact-value operations includes
       the exact-value data types (<literal role="type">DECIMAL</literal>
       and integer types) and exact-value numeric literals.
-      Approximate-value data types and numeric literals still are
-      handled as floating-point numbers.
+      Approximate-value data types and numeric literals are handled as
+      floating-point numbers.
     </para>
 
     <para>

@@ -179,11 +174,10 @@
     </para>
 
     <para>
-      Two numbers that look similar need not be both exact-value or both
-      approximate-value. For example, <literal>2.34</literal> is an
-      exact-value (fixed-point) number, whereas
-      <literal>2.34E0</literal> is an approximate-value (floating-point)
-      number.
+      Two numbers that look similar may be treated differently. For
+      example, <literal>2.34</literal> is an exact-value (fixed-point)
+      number, whereas <literal>2.34E0</literal> is an approximate-value
+      (floating-point) number.
     </para>
 
     <para>

@@ -287,21 +281,21 @@
       that calculations on <literal role="type">DECIMAL</literal> values
       are accurate up to 65 digits. This limit of 65 digits of precision
       also applies to exact-value numeric literals, so the maximum range
-      of such literals is different from before. (In older versions of
-      MySQL, decimal values could have up to 254 digits. However,
-      calculations were done using floating-point and thus were
-      approximate, not exact.)
+      of such literals differs from before. (In older versions of MySQL,
+      decimal values could have up to 254 digits. However, calculations
+      were done using floating-point and thus were approximate, not
+      exact.)
     </para>
 
     <para>
       Values for <literal role="type">DECIMAL</literal> columns in MySQL
       &current-series; are stored using a binary format that packs nine
-      decimal digits into four bytes. The storage requirements for the
+      decimal digits into 4 bytes. The storage requirements for the
       integer and fractional parts of each value are determined
-      separately. Each multiple of nine digits requires four bytes, and
-      any remaining digits left over require some fraction of four
-      bytes. The storage required for remaining digits is given by the
-      following table.
+      separately. Each multiple of nine digits requires 4 bytes, and any
+      remaining digits left over require some fraction of 4 bytes. The
+      storage required for remaining digits is given by the following
+      table.
     </para>
 
     <informaltable>

@@ -318,41 +312,21 @@
             <entry>0</entry>
           </row>
           <row>
+            <entry>1&ndash;2</entry>
             <entry>1</entry>
-            <entry>1</entry>
           </row>
           <row>
+            <entry>3&ndash;4</entry>
             <entry>2</entry>
-            <entry>1</entry>
           </row>
           <row>
+            <entry>5&ndash;6</entry>
             <entry>3</entry>
-            <entry>2</entry>
           </row>
           <row>
+            <entry>7&ndash;9</entry>
             <entry>4</entry>
-            <entry>2</entry>
           </row>
-          <row>
-            <entry>5</entry>
-            <entry>3</entry>
-          </row>
-          <row>
-            <entry>6</entry>
-            <entry>3</entry>
-          </row>
-          <row>
-            <entry>7</entry>
-            <entry>4</entry>
-          </row>
-          <row>
-            <entry>8</entry>
-            <entry>4</entry>
-          </row>
-          <row>
-            <entry>9</entry>
-            <entry>4</entry>
-          </row>
         </tbody>
       </tgroup>
     </informaltable>

@@ -360,11 +334,11 @@
     <para>
       For example, a <literal>DECIMAL(18,9)</literal> column has nine
       digits on either side of the decimal point, so the integer part
-      and the fractional part each require four bytes. A
+      and the fractional part each require 4 bytes. A
       <literal>DECIMAL(20,6)</literal> column has fourteen integer
       digits and six fractional digits. The integer digits require four
-      bytes for nine of the digits and three bytes for the remaining
-      five digits. The six fractional digits require three bytes.
+      bytes for nine of the digits and 3 bytes for the remaining five
+      digits. The six fractional digits require 3 bytes.
     </para>
 
     <para>


Modified: trunk/refman-5.6/data-types.xml
===================================================================
--- trunk/refman-5.6/data-types.xml	2010-10-15 15:15:18 UTC (rev 23158)
+++ trunk/refman-5.6/data-types.xml	2010-10-15 16:21:16 UTC (rev 23159)
Changed blocks: 1, Lines Added: 4, Lines Deleted: 4; 1168 bytes

@@ -2231,10 +2231,10 @@
       <literal role="type">REAL</literal>, and
       <literal role="type">DOUBLE PRECISION</literal>). The keyword
       <literal role="type">INT</literal> is a synonym for
-      <literal role="type">INTEGER</literal>, and the keyword
-      <literal role="type">DEC</literal> is a synonym for
-      <literal role="type">DECIMAL</literal>. MySQL treats
-      <literal role="type">DOUBLE</literal> as a synonym for
+      <literal role="type">INTEGER</literal>, and the keywords
+      <literal role="type">DEC</literal> and <literal>FIXED</literal>
+      are synonyms for <literal role="type">DECIMAL</literal>. MySQL
+      treats <literal role="type">DOUBLE</literal> as a synonym for
       <literal role="type">DOUBLE PRECISION</literal> (a nonstandard
       extension). MySQL also treats <literal role="type">REAL</literal>
       as a synonym for <literal role="type">DOUBLE PRECISION</literal>


Modified: trunk/refman-5.6/functions-core.xml
===================================================================
--- trunk/refman-5.6/functions-core.xml	2010-10-15 15:15:18 UTC (rev 23158)
+++ trunk/refman-5.6/functions-core.xml	2010-10-15 16:21:16 UTC (rev 23159)
Changed blocks: 2, Lines Added: 5, Lines Deleted: 6; 1230 bytes

@@ -6174,12 +6174,11 @@
 
         <listitem>
           <para>
-            If one of the operands is an unsigned integer, and the other
-            operand is also an integer, the result is an unsigned
-            integer. For subtraction, if the
+            If both operands are integers and any of them are unsigned,
+            the result is an unsigned integer. For subtraction, if the
             <literal role="sqlmode">NO_UNSIGNED_SUBTRACTION</literal>
-            SQL mode is enabled, the subtraction result is signed even
-            if any operand is unsigned.
+            SQL mode is enabled, the result is signed even if any
+            operand is unsigned.
           </para>
         </listitem>
 

@@ -6230,7 +6229,7 @@
 
       <para>
         For information about handling of overflow in numeric expression
-        evaluation, see <xref linkend="numeric-types"/>.
+        evaluation, see <xref linkend="out-of-range-and-overflow"/>.
       </para>
 
       <para>


Modified: trunk/refman-5.6/precision-math.xml
===================================================================
--- trunk/refman-5.6/precision-math.xml	2010-10-15 15:15:18 UTC (rev 23158)
+++ trunk/refman-5.6/precision-math.xml	2010-10-15 16:21:16 UTC (rev 23159)
Changed blocks: 8, Lines Added: 34, Lines Deleted: 60; 7062 bytes

@@ -83,7 +83,8 @@
   </itemizedlist>
 
   <para>
-    These features have several implications for numeric operations:
+    These features have several implications for numeric operations and
+    provide a high degree of compliance with standard SQL:
   </para>
 
   <itemizedlist>

@@ -93,10 +94,11 @@
         <emphasis role="bold">Precise calculations</emphasis>: For
         exact-value numbers, calculations do not introduce
         floating-point errors. Instead, exact precision is used. For
-        example, a number such as <literal>.0001</literal> is treated as
-        an exact value rather than as an approximation, and summing it
-        10,000 times produces a result of exactly <literal>1</literal>,
-        not a value that merely <quote>close</quote> to 1.
+        example, MySQL treats a number such as <literal>.0001</literal>
+        as an exact value rather than as an approximation, and summing
+        it 10,000 times produces a result of exactly
+        <literal>1</literal>, not a value that is merely
+        <quote>close</quote> to 1.
       </para>
     </listitem>
 

@@ -128,26 +130,19 @@
         type. Similarly, you can treat division by zero as an error
         rather than as an operation that produces a result of
         <literal>NULL</literal>. The choice of which approach to take is
-        determined by the setting of the
-        <literal role="sysvar">sql_mode</literal> system variable.
+        determined by the setting of the server SQL mode.
       </para>
     </listitem>
 
   </itemizedlist>
 
   <para>
-    An important result of these features is that MySQL &current-series;
-    provides a high degree of compliance with standard SQL.
-  </para>
-
-  <para>
     The following discussion covers several aspects of how precision
-    math works (including possible incompatibilities with older
-    applications). At the end, some examples are given that demonstrate
+    math works, including possible incompatibilities with older
+    applications. At the end, some examples are given that demonstrate
     how MySQL &current-series; handles numeric operations precisely. For
-    information about using the
-    <literal role="sysvar">sql_mode</literal> system variable to control
-    the SQL mode, see <xref linkend="server-sql-mode"/>.
+    information about controlling the SQL mode, see
+    <xref linkend="server-sql-mode"/>.
   </para>
 
   <section id="precision-math-numbers">

@@ -158,8 +153,8 @@
       The scope of precision math for exact-value operations includes
       the exact-value data types (<literal role="type">DECIMAL</literal>
       and integer types) and exact-value numeric literals.
-      Approximate-value data types and numeric literals still are
-      handled as floating-point numbers.
+      Approximate-value data types and numeric literals are handled as
+      floating-point numbers.
     </para>
 
     <para>

@@ -179,11 +174,10 @@
     </para>
 
     <para>
-      Two numbers that look similar need not be both exact-value or both
-      approximate-value. For example, <literal>2.34</literal> is an
-      exact-value (fixed-point) number, whereas
-      <literal>2.34E0</literal> is an approximate-value (floating-point)
-      number.
+      Two numbers that look similar may be treated differently. For
+      example, <literal>2.34</literal> is an exact-value (fixed-point)
+      number, whereas <literal>2.34E0</literal> is an approximate-value
+      (floating-point) number.
     </para>
 
     <para>

@@ -287,21 +281,21 @@
       that calculations on <literal role="type">DECIMAL</literal> values
       are accurate up to 65 digits. This limit of 65 digits of precision
       also applies to exact-value numeric literals, so the maximum range
-      of such literals is different from before. (In older versions of
-      MySQL, decimal values could have up to 254 digits. However,
-      calculations were done using floating-point and thus were
-      approximate, not exact.)
+      of such literals differs from before. (In older versions of MySQL,
+      decimal values could have up to 254 digits. However, calculations
+      were done using floating-point and thus were approximate, not
+      exact.)
     </para>
 
     <para>
       Values for <literal role="type">DECIMAL</literal> columns in MySQL
       &current-series; are stored using a binary format that packs nine
-      decimal digits into four bytes. The storage requirements for the
+      decimal digits into 4 bytes. The storage requirements for the
       integer and fractional parts of each value are determined
-      separately. Each multiple of nine digits requires four bytes, and
-      any remaining digits left over require some fraction of four
-      bytes. The storage required for remaining digits is given by the
-      following table.
+      separately. Each multiple of nine digits requires 4 bytes, and any
+      remaining digits left over require some fraction of 4 bytes. The
+      storage required for remaining digits is given by the following
+      table.
     </para>
 
     <informaltable>

@@ -318,41 +312,21 @@
             <entry>0</entry>
           </row>
           <row>
+            <entry>1&ndash;2</entry>
             <entry>1</entry>
-            <entry>1</entry>
           </row>
           <row>
+            <entry>3&ndash;4</entry>
             <entry>2</entry>
-            <entry>1</entry>
           </row>
           <row>
+            <entry>5&ndash;6</entry>
             <entry>3</entry>
-            <entry>2</entry>
           </row>
           <row>
+            <entry>7&ndash;9</entry>
             <entry>4</entry>
-            <entry>2</entry>
           </row>
-          <row>
-            <entry>5</entry>
-            <entry>3</entry>
-          </row>
-          <row>
-            <entry>6</entry>
-            <entry>3</entry>
-          </row>
-          <row>
-            <entry>7</entry>
-            <entry>4</entry>
-          </row>
-          <row>
-            <entry>8</entry>
-            <entry>4</entry>
-          </row>
-          <row>
-            <entry>9</entry>
-            <entry>4</entry>
-          </row>
         </tbody>
       </tgroup>
     </informaltable>

@@ -360,11 +334,11 @@
     <para>
       For example, a <literal>DECIMAL(18,9)</literal> column has nine
       digits on either side of the decimal point, so the integer part
-      and the fractional part each require four bytes. A
+      and the fractional part each require 4 bytes. A
       <literal>DECIMAL(20,6)</literal> column has fourteen integer
       digits and six fractional digits. The integer digits require four
-      bytes for nine of the digits and three bytes for the remaining
-      five digits. The six fractional digits require three bytes.
+      bytes for nine of the digits and 3 bytes for the remaining five
+      digits. The six fractional digits require 3 bytes.
     </para>
 
     <para>


Modified: trunk/refman-6.0/data-types.xml
===================================================================
--- trunk/refman-6.0/data-types.xml	2010-10-15 15:15:18 UTC (rev 23158)
+++ trunk/refman-6.0/data-types.xml	2010-10-15 16:21:16 UTC (rev 23159)
Changed blocks: 1, Lines Added: 4, Lines Deleted: 4; 1168 bytes

@@ -2231,10 +2231,10 @@
       <literal role="type">REAL</literal>, and
       <literal role="type">DOUBLE PRECISION</literal>). The keyword
       <literal role="type">INT</literal> is a synonym for
-      <literal role="type">INTEGER</literal>, and the keyword
-      <literal role="type">DEC</literal> is a synonym for
-      <literal role="type">DECIMAL</literal>. MySQL treats
-      <literal role="type">DOUBLE</literal> as a synonym for
+      <literal role="type">INTEGER</literal>, and the keywords
+      <literal role="type">DEC</literal> and <literal>FIXED</literal>
+      are synonyms for <literal role="type">DECIMAL</literal>. MySQL
+      treats <literal role="type">DOUBLE</literal> as a synonym for
       <literal role="type">DOUBLE PRECISION</literal> (a nonstandard
       extension). MySQL also treats <literal role="type">REAL</literal>
       as a synonym for <literal role="type">DOUBLE PRECISION</literal>


Modified: trunk/refman-6.0/functions-core.xml
===================================================================
--- trunk/refman-6.0/functions-core.xml	2010-10-15 15:15:18 UTC (rev 23158)
+++ trunk/refman-6.0/functions-core.xml	2010-10-15 16:21:16 UTC (rev 23159)
Changed blocks: 2, Lines Added: 5, Lines Deleted: 6; 1230 bytes

@@ -6216,12 +6216,11 @@
 
         <listitem>
           <para>
-            If one of the operands is an unsigned integer, and the other
-            operand is also an integer, the result is an unsigned
-            integer. For subtraction, if the
+            If both operands are integers and any of them are unsigned,
+            the result is an unsigned integer. For subtraction, if the
             <literal role="sqlmode">NO_UNSIGNED_SUBTRACTION</literal>
-            SQL mode is enabled, the subtraction result is signed even
-            if any operand is unsigned.
+            SQL mode is enabled, the result is signed even if any
+            operand is unsigned.
           </para>
         </listitem>
 

@@ -6272,7 +6271,7 @@
 
       <para>
         For information about handling of overflow in numeric expression
-        evaluation, see <xref linkend="numeric-types"/>.
+        evaluation, see <xref linkend="out-of-range-and-overflow"/>.
       </para>
 
       <para>


Modified: trunk/refman-6.0/precision-math.xml
===================================================================
--- trunk/refman-6.0/precision-math.xml	2010-10-15 15:15:18 UTC (rev 23158)
+++ trunk/refman-6.0/precision-math.xml	2010-10-15 16:21:16 UTC (rev 23159)
Changed blocks: 8, Lines Added: 34, Lines Deleted: 60; 7062 bytes

@@ -83,7 +83,8 @@
   </itemizedlist>
 
   <para>
-    These features have several implications for numeric operations:
+    These features have several implications for numeric operations and
+    provide a high degree of compliance with standard SQL:
   </para>
 
   <itemizedlist>

@@ -93,10 +94,11 @@
         <emphasis role="bold">Precise calculations</emphasis>: For
         exact-value numbers, calculations do not introduce
         floating-point errors. Instead, exact precision is used. For
-        example, a number such as <literal>.0001</literal> is treated as
-        an exact value rather than as an approximation, and summing it
-        10,000 times produces a result of exactly <literal>1</literal>,
-        not a value that merely <quote>close</quote> to 1.
+        example, MySQL treats a number such as <literal>.0001</literal>
+        as an exact value rather than as an approximation, and summing
+        it 10,000 times produces a result of exactly
+        <literal>1</literal>, not a value that is merely
+        <quote>close</quote> to 1.
       </para>
     </listitem>
 

@@ -128,26 +130,19 @@
         type. Similarly, you can treat division by zero as an error
         rather than as an operation that produces a result of
         <literal>NULL</literal>. The choice of which approach to take is
-        determined by the setting of the
-        <literal role="sysvar">sql_mode</literal> system variable.
+        determined by the setting of the server SQL mode.
       </para>
     </listitem>
 
   </itemizedlist>
 
   <para>
-    An important result of these features is that MySQL &current-series;
-    provides a high degree of compliance with standard SQL.
-  </para>
-
-  <para>
     The following discussion covers several aspects of how precision
-    math works (including possible incompatibilities with older
-    applications). At the end, some examples are given that demonstrate
+    math works, including possible incompatibilities with older
+    applications. At the end, some examples are given that demonstrate
     how MySQL &current-series; handles numeric operations precisely. For
-    information about using the
-    <literal role="sysvar">sql_mode</literal> system variable to control
-    the SQL mode, see <xref linkend="server-sql-mode"/>.
+    information about controlling the SQL mode, see
+    <xref linkend="server-sql-mode"/>.
   </para>
 
   <section id="precision-math-numbers">

@@ -158,8 +153,8 @@
       The scope of precision math for exact-value operations includes
       the exact-value data types (<literal role="type">DECIMAL</literal>
       and integer types) and exact-value numeric literals.
-      Approximate-value data types and numeric literals still are
-      handled as floating-point numbers.
+      Approximate-value data types and numeric literals are handled as
+      floating-point numbers.
     </para>
 
     <para>

@@ -179,11 +174,10 @@
     </para>
 
     <para>
-      Two numbers that look similar need not be both exact-value or both
-      approximate-value. For example, <literal>2.34</literal> is an
-      exact-value (fixed-point) number, whereas
-      <literal>2.34E0</literal> is an approximate-value (floating-point)
-      number.
+      Two numbers that look similar may be treated differently. For
+      example, <literal>2.34</literal> is an exact-value (fixed-point)
+      number, whereas <literal>2.34E0</literal> is an approximate-value
+      (floating-point) number.
     </para>
 
     <para>

@@ -287,21 +281,21 @@
       that calculations on <literal role="type">DECIMAL</literal> values
       are accurate up to 65 digits. This limit of 65 digits of precision
       also applies to exact-value numeric literals, so the maximum range
-      of such literals is different from before. (In older versions of
-      MySQL, decimal values could have up to 254 digits. However,
-      calculations were done using floating-point and thus were
-      approximate, not exact.)
+      of such literals differs from before. (In older versions of MySQL,
+      decimal values could have up to 254 digits. However, calculations
+      were done using floating-point and thus were approximate, not
+      exact.)
     </para>
 
     <para>
       Values for <literal role="type">DECIMAL</literal> columns in MySQL
       &current-series; are stored using a binary format that packs nine
-      decimal digits into four bytes. The storage requirements for the
+      decimal digits into 4 bytes. The storage requirements for the
       integer and fractional parts of each value are determined
-      separately. Each multiple of nine digits requires four bytes, and
-      any remaining digits left over require some fraction of four
-      bytes. The storage required for remaining digits is given by the
-      following table.
+      separately. Each multiple of nine digits requires 4 bytes, and any
+      remaining digits left over require some fraction of 4 bytes. The
+      storage required for remaining digits is given by the following
+      table.
     </para>
 
     <informaltable>

@@ -318,41 +312,21 @@
             <entry>0</entry>
           </row>
           <row>
+            <entry>1&ndash;2</entry>
             <entry>1</entry>
-            <entry>1</entry>
           </row>
           <row>
+            <entry>3&ndash;4</entry>
             <entry>2</entry>
-            <entry>1</entry>
           </row>
           <row>
+            <entry>5&ndash;6</entry>
             <entry>3</entry>
-            <entry>2</entry>
           </row>
           <row>
+            <entry>7&ndash;9</entry>
             <entry>4</entry>
-            <entry>2</entry>
           </row>
-          <row>
-            <entry>5</entry>
-            <entry>3</entry>
-          </row>
-          <row>
-            <entry>6</entry>
-            <entry>3</entry>
-          </row>
-          <row>
-            <entry>7</entry>
-            <entry>4</entry>
-          </row>
-          <row>
-            <entry>8</entry>
-            <entry>4</entry>
-          </row>
-          <row>
-            <entry>9</entry>
-            <entry>4</entry>
-          </row>
         </tbody>
       </tgroup>
     </informaltable>

@@ -360,11 +334,11 @@
     <para>
       For example, a <literal>DECIMAL(18,9)</literal> column has nine
       digits on either side of the decimal point, so the integer part
-      and the fractional part each require four bytes. A
+      and the fractional part each require 4 bytes. A
       <literal>DECIMAL(20,6)</literal> column has fourteen integer
       digits and six fractional digits. The integer digits require four
-      bytes for nine of the digits and three bytes for the remaining
-      five digits. The six fractional digits require three bytes.
+      bytes for nine of the digits and 3 bytes for the remaining five
+      digits. The six fractional digits require 3 bytes.
     </para>
 
     <para>


Thread
svn commit - mysqldoc@docsrva: r23159 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-5.5 refman-5.6 refman-6.0paul.dubois15 Oct