List:Internals« Previous MessageNext Message »
From:paul Date:March 31 2005 4:11am
Subject:bk commit - mysqldoc tree (paul:1.2789)
View as plain text  
Below is the list of changes that have just been committed into a local
mysqldoc repository of paul. When paul does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://www.mysql.com/doc/I/n/Installing_source_tree.html

ChangeSet
  1.2789 05/03/30 22:11:13 paul@stripped +1 -0
  manual.texi:
    Note that BIT is MyISAM-only for the moment.
    Cleanups

  Docs/manual.texi
    1.2619 05/03/30 21:58:16 paul@stripped +3 -1
    Note that BIT is MyISAM-only for the moment.

  Docs/manual.texi
    1.2618 05/03/30 21:54:13 paul@stripped +29 -28
    Cleanups

# This is a BitKeeper patch.  What follows are the unified diffs for the
# set of deltas contained in the patch.  The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User:	paul
# Host:	frost.snake.net
# Root:	/Volumes/frost2/MySQL/bk/mysqldoc

--- 1.2617/Docs/manual.texi	2005-03-30 18:43:35 -06:00
+++ 1.2619/Docs/manual.texi	2005-03-30 21:58:16 -06:00
@@ -45009,7 +45009,8 @@
 @item BIT[(@var{M})]
 
 A bit-field type. @var{M} indicates the number of bits per value, from 1 to
-64. The default is 1 if @var{M} is omitted.
+64. The default is 1 if @var{M} is omitted.  Currently, @code{BIT} is
+supported only for @code{MyISAM}.
 
 This data type was added in MySQL 5.0.3.  Before 5.0.3, @code{BIT} is a
 synonym for @code{TINYINT(1)}.
@@ -45191,10 +45192,10 @@
 
 For MySQL 5.0.3 and above:
 
-An packed 'exact' fixed-point number. @var{M} is the total number of
+A packed ``exact'' fixed-point number. @var{M} is the total number of
 digits and @var{D} is the number of decimals.  The decimal point and
-(for negative numbers) the @samp{-} sign are not counted in @var{M},
-although space for them is reserved. If @var{D} is 0, values have no
+(for negative numbers) the @samp{-} sign are not counted in @var{M}.
+If @var{D} is 0, values have no
 decimal point or fractional part.  The maximum number of digits
 (@var{M}) for @code{DECIMAL} is 64. The maximum number of supported
 decimals (@var{D}) is 30.  If @code{UNSIGNED} is specified, negative
@@ -45203,10 +45204,10 @@
 If @var{D} is omitted, the default is 0.  If @var{M} is omitted, the
 default is 10.
 
-All basic calculation (@code{+,-,*,/}) with @code{DECIMAL} columns are
+All basic calculations (@code{+, -, *, /}) with @code{DECIMAL} columns are
 done with a precision of 64 decimal digits.
 
-For MySQL version before 5.0.3:
+Before MySQL 5.0.3:
 
 An unpacked fixed-point number.  Behaves like a @code{CHAR} column;
 ``unpacked'' means the number is stored as a string, using one character for
@@ -45222,10 +45223,11 @@
 If @var{D} is omitted, the default is 0.  If @var{M} is omitted, the
 default is 10.
 
-Prior to MySQL 3.23:
+Before MySQL 3.23:
 
-Like above, but with the exception that @var{M} argument had to be large
-enough to include the space needed for the sign and the decimal point.
+As just described, with the exception that the @var{M} value must be large
+enough to include the space needed for the sign and the decimal point
+characters.
 
 @tindex DEC data type
 @tindex NUMERIC data type
@@ -45643,6 +45645,7 @@
 
 As of MySQL 5.0.3, a @code{BIT} data type is available for storing bit-field
 values. (Before 5.0.3, MySQL interprets @code{BIT} as @code{TINYINT(1)}.)
+Currently, @code{BIT} is supported only for @code{MyISAM}.
 
 As an extension to the SQL standard, MySQL also supports the integer types
 @code{TINYINT}, @code{MEDIUMINT}, and @code{BIGINT}. The following table
@@ -47326,7 +47329,7 @@
 @code{DECIMAL} columns are done with precision of 64 decimal digits.
 @xref{Numeric type overview}.
 
-For earlier MySQL version accurate representation of monetary values was
+For earlier MySQL version, accurate representation of monetary values was
 a common problem. In these MySQL version, you should also use the
 @code{DECIMAL} type. In this case the value is stored as a string, so no
 loss of accuracy should occur on storage.  Calculations on these
@@ -47335,7 +47338,7 @@
 the @code{DOUBLE} type may also be good enough.
 
 For high precision, you can always convert to a fixed-point type stored
-in a @code{BIGINT}. This allows you to do all calculations with 64 bit
+in a @code{BIGINT}. This allows you to do all calculations with 64-bit
 integers and convert results back to floating-point values only when
 necessary.
 
@@ -50905,8 +50908,8 @@
 description. All other characters are just taken verbatim, thus not being
 interpreted.
 If @var{str} contains an illegal date, time, or datetime value,
-@code{STR_TO_DATE()} returns @code{NULL}.  Starting from MySQL 5.0.3 an illegal
-value will also produce a warning.
+@code{STR_TO_DATE()} returns @code{NULL}.  Starting from MySQL 5.0.3, an
+illegal value also produces a warning.
 @c end_description_for_help_topic
 
 @c example_for_help_topic STR_TO_DATE
@@ -65270,8 +65273,8 @@
 @itemize @bullet
 
 @item
-@code{CHAR} columns (and @code{NUMERIC}, and @code{DECIMAL} created before
-MySQL 5.0.3) are space-padded to the column width.
+@code{CHAR} columns are space-padded to the column width.  This is also true
+for @code{NUMERIC}, and @code{DECIMAL} columns created before MySQL 5.0.3.
 
 @item
 Very quick.
@@ -96214,12 +96217,12 @@
 @node Problems with float,  , No matching rows, Query Issues
 @appendixsubsec Problems with Floating-Point Comparisons
 
-Note that the following section is mainly relevant for MySQL version older
-than 5.0.3.  In MySQL 5.0.3 and above we are calculating operations with
-@code{DECIMAL} with 56 bit precession, which should solve most common
-inaccuracy problems when it comes to @code{DECIMAL} columns.
-For @code{DOUBLE} and @code{FLOAT} columns the problems still remains
-as inexactness is the basic nature of floating point numbers.
+Note that the following section is relevant primarily for versions of MySQL
+older than 5.0.3.  As of version 5.0.3, MySQL performs @code{DECIMAL}
+operations with a precision of 64 decimal digits, which should solve most
+common inaccuracy problems when it comes to @code{DECIMAL} columns.  For
+@code{DOUBLE} and @code{FLOAT} columns, the problems remain because
+inexactness is the basic nature of floating point numbers.
 
 @c TODO: update for precision math
 
@@ -96228,13 +96231,13 @@
 can see on the screen usually is not the exact value of the number.
 The column types @code{FLOAT}, @code{DOUBLE}, and @code{DECIMAL} are such.
 @code{DECIMAL} columns store values with exact precision because they are
-represented as strings, but calculations on @code{DECIMAL} values is before
-MYSQL 5.0.30 done using floating-point operations.
+represented as strings, but calculations on @code{DECIMAL} values before
+MySQL 5.0.3 are done using floating-point operations.
 
 The following example (for older MySQL version than 5.0.3) demonstrate
 the problem. It shows that even for the @code{DECIMAL} column type,
 calculations that are done using floating-point operations are subject
-to floating-point error.  (In all MYSQL versions, you would have similar
+to floating-point error.  (In all MySQL versions, you would have similar
 problems if you would replace the @code{DECIMAL} columns with @code{FLOAT}).
 
 @example
@@ -96266,7 +96269,7 @@
 the numbers shows up around the tenth decimal or so, depending on computer
 architecture.
 
-In MySQL 5.0.3 you will only get the last row in the above result.
+As of MySQL 5.0.3, you will get only the last row in the above result.
 
 The problem cannot be solved by using @code{ROUND()} or similar functions,
 because the result is still a floating-point number:
@@ -97932,11 +97935,11 @@
 Bugs fixed:
 @itemize @bullet
 @item
-Inserting a zero date in a @code{DATETIME} field during @code{traditional} mode
-now produces an error.
+Inserting a zero date into a @code{DATETIME} column in @code{traditional}
+mode now produces an error.
 @item
-@code{STR_TO_DATE()} now produces warnings in normal mode and errors in
-@code{strict mode}.
+@code{STR_TO_DATE()} now produces errors in strict mode (and warnings
+otherwise) when given an illegal argument.
 @item
 Fixed a problem with @code{ORDER BY} that sometimes caused incorrect sorting
 of @code{utf8} data.  (Bug #9309)
Thread
bk commit - mysqldoc tree (paul:1.2789)paul31 Mar