bk commit - mysqldoc@docsrva tree (Mike.Hillyer:1.2728)

[mhillyer]

Below is the list of changes that have just been committed into a local
mysqldoc repository of root. When root 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.2728 05/05/30 17:20:18 Mike.Hillyer@stripped +2 -0
  MT: Implemented some feedback from MikeZ.
  Refman: Moved known issues section. Improved entries.

  migration-toolkit/migration-toolkit.xml
    1.10 05/05/30 17:20:17 Mike.Hillyer@stripped +12 -9
    Implemented some feedback from MikeZ.

  Docs/manual.texi
    1.2947 05/05/30 17:20:16 Mike.Hillyer@stripped +417 -465
    Moved know issues to the end of the problems appendix, renamed sections to be about
Known Issues. Reformatted items to speak of version fixed in first. Improved wording of
many items.

# 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:	Mike.Hillyer
# Host:	www.openwin.org
# Root:	/home/mysqldoc/mysqldoc2

--- 1.9/migration-toolkit/migration-toolkit.xml	2005-05-30 15:20:08 -06:00
+++ 1.10/migration-toolkit/migration-toolkit.xml	2005-05-30 17:20:17 -06:00
@@ -1121,9 +1121,9 @@
 
    <para>
     One of the key features of the &migration_toolkit; is that it can be
-    easily extended to support new data sources. Through the use of its
+    easily extended and customized to support new data sources. Through the use of its
     Generic RunTime Environment (<literal>GRT</literal>), the
-    &migration_toolkit; can support new features and data sources using
+    &migration_toolkit; can support new behaviour and data sources using
     code written in languages such as Java, PHP, and C.
    </para>
 
@@ -1137,6 +1137,10 @@
     the the target MySQL server objects.
    </para>
 
+  <para>
+  Existing modules can be easily expanded and customzed to achieve the perfect migration
for individual requirements. New migration "methods" that define how the migration is
performed can be added easily. The new methods are listed and can be selected by the end
user in the Wizard interface or used in migration scripts.
+</para> 
+
   </sect1>
 
 <!-- END INTRODUCTION -->
@@ -1149,7 +1153,7 @@
     The &migration_toolkit; is written on top of the Generic Runtime
     Environment (GRT): a thin C layer, inspired by Objective C, which
     allows for dynamic typing and dynamic data objects. The GRT supports
-    the creation of new modules written in C, Java, PHP, and Lua.
+    the creation of new modules written in C, Java, PHP, and Lua, with support for Python
and Mono forthcoming.
    </para>
 
    <para>
@@ -1173,15 +1177,14 @@
 
    <para>
     Transformation modules convert the MySQL GRT objects into the actual
-    SQL statements used to create and load data into the target MySQL
-    server. Transformation modules will have a name similar to
+    SQL statements used to create objects such as tables and views on the target MySQL
server. Transformation modules will have a name similar to
     <literal>TransformationMySQL</literal>. Transformation modules are
     supplied by the MySQL GUI team and need not be created to add
     support for a new source database.
    </para>
 
    <para>
-    Reverse engineering and migration modules are derived from base
+    All modules are derived from base
     classes whose methods can be re-written to match the new source
     database.
    </para>
@@ -1203,7 +1206,7 @@
 
     <listitem><para>
      The &migration_toolkit; prompts the user for a source database and
-     connection parameters. The user selection determines which moldules
+     connection parameters. The user selection determines which modules
      will be used for the source database.
     </para></listitem>
 
@@ -1222,7 +1225,7 @@
     </para></listitem>
 
     <listitem><para>
-     Once the user has selected a schema to migrate, the
+     Once the user has selected one or more schema to migrate, the
      &migration_toolkit; calls the <literal>reverseEngineer</literal>
      method of the reverse engineering module. The
      <literal>reverseEngineer</literal> method converts all objects in
@@ -1244,7 +1247,7 @@
      Once the user has selected the migration methods, the
      &migration_toolkit; calls the <literal>migrate</literal> method of
      the migration module. The <literal>migrate</literal> method
-     converts the source RDBMS GRT objects into MySQL GRT objects.
+     converts the source RDBMS GRT objects into MySQL GRT objects by calling the selected
migration method for each source schema object. If no explicit method is assigned, the
default migration method for the object type will be used.
     </para></listitem>
 
     <listitem><para>

--- 1.2946/Docs/manual.texi	2005-05-30 01:52:53 -06:00
+++ 1.2947/Docs/manual.texi	2005-05-30 17:20:16 -06:00
@@ -2126,7 +2126,6 @@
 * Extensions to ANSI::          MySQL Extensions to Standard SQL
 * Differences from ANSI::       MySQL Differences from Standard SQL
 * Constraints::                 How MySQL Deals with Constraints
-* Bugs::                        Known Errors and Design Deficiencies in MySQL
 @end menu
 
 
@@ -3015,7 +3014,7 @@
 @end example
 
 
-@node Constraints, Bugs, Differences from ANSI, Compatibility
+@node Constraints,  , Differences from ANSI, Compatibility
 @subsection How MySQL Deals with Constraints
 
 @findex constraints
@@ -3254,467 +3253,6 @@
 that any invalid substrings are deleted. For example, @code{'a,x,b,y'}
 results in a value of @code{'a,b'}, as described earlier.
 
-
-@node Bugs,  , Constraints, Compatibility
-@subsection Known Errors and Design Deficiencies in MySQL
-
-@cindex bugs, known
-@cindex errors, known
-@cindex design, issues
-@cindex known errors
-
-@menu
-* Errors in 3.23::              Errors in 3.23 Fixed in a Later MySQL Version
-* Errors in 4.0::               Errors in 4.0 Fixed in a Later MySQL Version
-* Errors in 4.1::               Errors in 4.1 Fixed in a Later MySQL Version
-* Open bugs::                   Open Bugs and Design Deficiencies in MySQL
-@end menu
-
-@node Errors in 3.23, Errors in 4.0, Bugs, Bugs
-@subsubsection Errors in 3.23 Fixed in a Later MySQL Version
-
-The following known errors or bugs are not fixed in MySQL 3.23 because fixing
-them would involve changing a lot of code that could introduce other
-even worse bugs. The bugs are also classified as ``not fatal'' or
-``bearable.''
-
-@itemize @bullet
-@item
-You should avoid using spaces at the end of column names because this can
-cause weird behavior. (Fixed in MySQL 4.0.) (Bug #4196)
-@item
-You can get a deadlock (hung thread) if you use @code{LOCK TABLE} to lock
-multiple tables and then in the same connection use @code{DROP TABLE} to
-drop one of them while another thread is trying to lock it.  (To break the
-deadlock, you can use @code{KILL} to terminate any of the threads involved.)
-This issue is resolved as of MySQL 4.0.12.
-@item
-@code{SELECT MAX(key_column) FROM t1,t2,t3...} where one of the tables are
-empty doesn't return @code{NULL} but instead returns the maximum value for the
-column.  This issue is resolved as of MySQL 4.0.11.
-@item
-@code{DELETE FROM heap_table} without a @code{WHERE} clause doesn't work on
-a locked @code{HEAP} table.
-@end itemize
-
-@node Errors in 4.0, Errors in 4.1, Errors in 3.23, Bugs
-@subsubsection Errors in 4.0 Fixed in a Later MySQL Version
-
-The following known errors or bugs are not fixed in MySQL 4.0 because fixing
-them would involve changing a lot of code that could introduce other
-even worse bugs. The bugs are also classified as ``not fatal'' or
-``bearable.''
-
-@itemize @bullet
-@item
-In @code{HAVING} you can get a crash or wrong result if you use an alias to
-a @code{RAND()} function. This is fixed in 4.1.10 but will not be fixed
-in 4.0 because the fix 'may' cause side effects for some applications.
-@item
-In a @code{UNION}, the first @code{SELECT} determines the type,
-@code{max_length}, and @code{NULL} properties for the resulting
-columns.  This issue is resolved as of MySQL 4.1.1; the property values are
-based on the rows from all @code{UNION} parts.
-@item
-In @code{DELETE} with many tables, you can't refer to tables to be
-deleted through an alias. This is fixed as of MySQL 4.1.
-@item
-You cannot mix @code{UNION ALL} and @code{UNION DISTINCT} in the same query.
-If you use @code{ALL} for one @code{UNION}, it is used for all
-of them.  This is fixed as of MySQL 4.1.2. The rules for mixed @code{UNION}
-types are given in @ref{UNION,  , @code{UNION}}.
-@item
-@code{FLUSH TABLES WITH READ LOCK} does not block @code{CREATE TABLE}, which
-may cause a problem with the binary log position when
-doing a full backup of tables and the binary log.
-@item
-@code{mysqldump --single-transaction --master-data} behaved like
-@code{mysqldump --master-data}, so the dump was a blocking one. This is fixed
-starting from MySQL 4.1.8.
-@item
-When using the @code{RPAD()} function (or any function adding spaces to the
-right) in a query that had to be resolved by using a temporary table, all
-resulting strings had rightmost spaces removed (i.e. @code{RPAD()} did not
-work).
-@end itemize
-
-@node Errors in 4.1, Open bugs, Errors in 4.0, Bugs
-@subsubsection Errors in 4.1 Fixed in a Later MySQL Version
-
-The following known errors or bugs are not fixed in MySQL 4.1 because fixing
-them would involve changing a lot of code that could introduce other
-even worse bugs. The bugs are also classified as ``not fatal'' or
-``bearable.''
-
-@itemize @bullet
-@code{VARCHAR} and @code{VARBINARY} did not remember end space.
-(Fixed in 5.0.3).
-@end itemize
-
-@node Open bugs,  , Errors in 4.1, Bugs
-@subsubsection Open Bugs and Design Deficiencies in MySQL
-
-The following problems are known and fixing them is a high priority:
-
-@itemize @bullet
-
-@item
-If you compare a @code{NULL} value to a subquery using @code{ALL/ANY/SOME}
-and the subquery returns an empty result, the comparison might evaluate
-to the non-standard result of @code{NULL} rather than to @code{TRUE} or
-@code{FALSE}. This will be fixed in MySQL 5.1.
-
-@item
-Subquery optimization for @code{IN} is not as good as for @code{=}.
-
-@item
-Even if you are using @code{lower_case_table_names=2} (which enables
-MySQL to remember the used case for databases and table names) MySQL
-does not remember the used case for database
-names for the function @code{DATABASE()} or in various logs (on case-insensitive
systems).
-
-@item
-Dropping a @code{FOREIGN KEY} constraint doesn't work in replication because
-the constraint may have another name on the slave.
-
-@item
-@code{REPLACE} (and @code{LOAD DATA} with the @code{REPLACE} option) does not
-trigger @code{ON DELETE CASCADE}.
-
-@item
-@code{DISTINCT} with @code{ORDER BY} doesn't work inside @code{GROUP_CONCAT()}
-if you don't use all and only those columns that are in the
-@code{DISTINCT} list.
-
-@item
-If one user has a long-running transaction and another user drops a
-table that is updated in the transaction, there is small chance that the
-binary log may contain the @code{DROP TABLE} command before the table is
-used in the transaction itself.  We plan to fix this by
-having the @code{DROP TABLE} wait until the table is not used in any
-transaction.
-
-@item
-When inserting a big integer value (between 2^63 and 2^64@minus{}1) into a
-decimal/string column, it is inserted as a negative value because
-the number is evaluated in a signed integer context.
-
-@item
-@code{FLUSH TABLES WITH READ LOCK} does not block @code{COMMIT} if the server
-is running without binary logging, which may cause a problem (of consistency
-between tables) when doing a full backup.
-
-@item
-@code{ANALYZE TABLE} on a @code{BDB} table may in some cases make the table
-unusable until you restart @command{mysqld}.  If this happens, look for
-errors of the following form in the MySQL error file:
-
-@example
-001207 22:07:56  bdb:  log_flush: LSN past current end-of-log
-@end example
-
-@item
-Don't execute @code{ALTER TABLE} on a @code{BDB} table on which you are
-running multiple-statement transactions until all those transactions complete.
-(The transaction might be ignored.)
-
-@item
-@code{ANALYZE TABLE}, @code{OPTIMIZE TABLE}, and @code{REPAIR TABLE} may
-cause problems on tables for which you are using @code{INSERT DELAYED}.
-
-@item
-Doing a @code{LOCK TABLE ...} and @code{FLUSH TABLES ...} doesn't
-guarantee that there isn't a half-finished transaction in progress on the
-table.
-
-@item
-@code{BDB} tables are a bit slow to open. If you have many @code{BDB} tables
-in a database, it takes a long time to use the @command{mysql} client on
-the database if you are not using the @code{-A} option or if you are using
-@code{rehash}. This is especially notable when you have a large table cache.
-
-@item
-Replication uses query-level logging: The master writes the executed
-queries to the binary log. This is a very fast, compact, and efficient
-logging method that works perfectly in most cases.
-Still it is
-possible for the data on the master and slave to become different if a
-query is designed in such a way that the data modification is
-non-deterministic; that is, left to the will of the query optimizer. (That
-generally is not a good practice anyway, even outside of replication!)
-For example:
-
-@itemize @minus
-@item
-@code{CREATE ... SELECT} or
-@code{INSERT ... SELECT}  statements that
-insert zero or @code{NULL} values into an @code{AUTO_INCREMENT} column.
-@item
-@code{DELETE} if you are
-deleting rows from a table that has foreign keys with @code{ON DELETE
-CASCADE} properties.
-@item
-@code{REPLACE ... SELECT},
-@code{INSERT IGNORE ... SELECT} if you have
-duplicate key values in the inserted data.
-@end itemize
-@strong{If and only if all these queries have no @code{ORDER BY}
-clause guaranteeing a deterministic order}.
-
-For example, for @code{INSERT ... SELECT} with no @code{ORDER
-BY}, the @code{SELECT} may return rows in a different order
-(which results in a row having different ranks, hence getting a
-different number in the @code{AUTO_INCREMENT} column),
-depending on the choices made by the optimizers on the master and
-slave. A query is optimized differently on the master and slave only if:
-
-@itemize @minus
-@item
-The files used by the two queries are not exactly the same; for
-example, @code{OPTIMIZE TABLE} was run on the master tables and not on
-the slave tables. (To fix this, @code{OPTIMIZE TABLE}, @code{ANALYZE TABLE},
-and @code{REPAIR TABLE} are written to the binary log as of MySQL 4.1.1).
-@item
-The table is stored using a different storage engine on the master than
-on the slave. (It is possible to use different storage engines on the master
-and slave. For example, you can use @code{InnoDB} on the master,
-but @code{MyISAM} on the slave if the slave has less available disk
-space.)
-@item
-MySQL buffer sizes (@code{key_buffer_size}, and so on) are different on
-the master and slave.
-@item
-The master and slave run different MySQL versions, and the optimizer
-code differs between these versions.
-@end itemize
-
-This problem may also affect database restoration using
-@command{mysqlbinlog|mysql}.
-
-The easiest way to avoid this problem in all cases is to add an
-@code{ORDER BY} clause to
-such non-deterministic queries to ensure that the rows are always
-stored or modified in the same order.
-In future MySQL versions, we will automatically add an @code{ORDER BY}
-clause when needed.
-
-@end itemize
-
-The following problems are known and will be fixed in due time:
-
-@itemize @bullet
-
-@item
-Log filenames are based on the server hostname (if you don't specify a
-filename with the startup option). You have to use options like
-@code{--log-bin=@var{old_host_name}-bin} if you change your hostname to something
-else. Another option is to just rename the old files to reflect your
-hostname change (and if these are binary logs, you also need to edit the
-binary log index file and fix the binlog names there). @xref{Server options}.
-
-@item
-@command{mysqlbinlog} does not delete temporary files left after a
-@code{LOAD DATA INFILE} command. @xref{mysqlbinlog,  , @command{mysqlbinlog}}.
-
-@item
-@code{RENAME} doesn't work with @code{TEMPORARY} tables or tables used in a
-@code{MERGE} table.
-
-@item
-Due to the way table definition files are stored, you cannot use
-character 255 (@code{CHAR(255)}) in table names, column names, or enumerations.
-This is scheduled to be fixed in version 5.1 when we have new table
-definition format files.
-
-@item
-When using @code{SET CHARACTER SET}, you can't use translated
-characters in database, table, and column names.
-
-@item
-You can't use @samp{_} or @samp{%} with @code{ESCAPE} in @code{LIKE
-... ESCAPE}.
-
-@item
-If you have a @code{DECIMAL} column in which the same number is stored in
-different formats (for example, @code{+01.00}, @code{1.00}, @code{01.00}),
-@code{GROUP BY} may regard each value as a different value.
-
-@item
-You cannot build the server in another directory when using
-MIT-pthreads. Because this requires changes to MIT-pthreads, we are not
-likely to fix this. @xref{MIT-pthreads}.
-
-@item
-@code{BLOB} and @code{TEXT}values can't ``reliably'' be used in @code{GROUP
-BY} or @code{ORDER BY} or @code{DISTINCT}. Only the first
-@code{max_sort_length} bytes are used when comparing @code{BLOB} values in
-these cases.  The default value of @code{max_sort_length} value is 1024. It
-can be changed at server startup time.  As of MySQL 4.0.3, it can also be
-changed at runtime. For older versions, a workaround for most cases is to
-use a substring.  For example:
-
-@example
-SELECT DISTINCT LEFT(@var{blob_col},2048) FROM @var{tbl_name};
-@end example
-
-@item
-Numeric
-calculations are done with @code{BIGINT} or @code{DOUBLE} (both are
-normally 64 bits long). Which precision you get depends on the function.
-The general rule is that bit functions are done with @code{BIGINT}
-precision, @code{IF} and @code{ELT()} with @code{BIGINT} or @code{DOUBLE}
-precision, and the rest with @code{DOUBLE} precision.  You should try to
-avoid using unsigned long long values if they resolve to be bigger than
-63 bits (9223372036854775807) for anything other than bit fields.
-MySQL Server 4.0 has better @code{BIGINT} handling than 3.23.
-
-@item
-You can have only up to 255 @code{ENUM} and @code{SET} columns in one table.
-
-@item
-In @code{MIN()}, @code{MAX()}, and other aggregate functions, MySQL
-currently compares @code{ENUM} and @code{SET} columns by their string
-value rather than by the string's relative position in the set.
-
-@item
-@command{mysqld_safe} redirects all messages from @command{mysqld} to the
-@command{mysqld} log.  One problem with this is that if you execute
-@command{mysqladmin refresh} to close and reopen the log,
-@code{stdout} and @code{stderr} are still redirected to the old log.
-If you use @code{--log} extensively, you should edit @command{mysqld_safe} to
-log to @file{@var{host_name}.err} instead of @file{@var{host_name}.log} so that you can
-easily reclaim the space for the old log by deleting the old one and
-executing @command{mysqladmin refresh}.
-
-@item
-In the @code{UPDATE} statement, columns are updated from left to right.  If
-you refer to an updated column, you get the updated value instead of the
-original value. For example, the following statement increments @code{KEY}
-by @code{2}, not @code{1}:
-
-@example
-mysql> UPDATE @var{tbl_name} SET KEY=KEY+1,KEY=KEY+1;
-@end example
-
-@item
-You can refer to multiple temporary tables in the same query, but
-you cannot refer to any given temporary table more than once.
-For example, the following doesn't work:
-
-@example
-mysql> SELECT * FROM temp_table, temp_table AS t2;
-ERROR 1137: Can't reopen table: 'temp_table'
-@end example
-
-@item
-The optimizer may handle @code{DISTINCT} differently when you are using
-``hidden'' columns in a join than when you are not.  In a join, hidden
-columns are counted as part of the result (even if they are not shown),
-whereas in normal queries, hidden columns don't participate in the
-@code{DISTINCT} comparison.  We will probably change this in the future to
-never compare the hidden columns when executing @code{DISTINCT}.
-
-An example of this is:
-
-@example
-SELECT DISTINCT mp3id FROM band_downloads
-       WHERE userid = 9 ORDER BY id DESC;
-@end example
-
-and
-
-@example
-SELECT DISTINCT band_downloads.mp3id
-       FROM band_downloads,band_mp3
-       WHERE band_downloads.userid = 9
-       AND band_mp3.id = band_downloads.mp3id
-       ORDER BY band_downloads.id DESC;
-@end example
-
-In the second case, you might in MySQL Server 3.23.x get two identical rows in
-the result set (because the values in the hidden @code{id} column may differ).
-
-Note that this happens only for queries where you don't have the
-@code{ORDER BY} columns in the result.
-
-@item
-Because MySQL Server allows you to work with table types that don't
-support transactions, and thus can't roll back data, some things
-behave a little differently in MySQL Server than in other SQL servers.
-This is just to ensure that MySQL Server never needs to do a rollback
-for an SQL statement.  This may be a little awkward at times because column
-values must be checked in the application, but this actually gives
-you a nice speed increase because it allows MySQL Server to do some
-optimizations that otherwise would be very hard to do.
-
-If you set a column to an incorrect value, MySQL Server, instead of
-doing a rollback, stores the ``best possible value'' in the column. For
-information about how this occurs, see @ref{Constraints}.
-
-@item
-If you execute a @code{PROCEDURE} on a query that returns an empty set,
-in some cases the @code{PROCEDURE} does not transform the columns.
-
-@item
-Creation of a table of type @code{MERGE} doesn't check whether the underlying
-tables are of compatible types.
-
-@item
-If you use @code{ALTER TABLE} first to add a @code{UNIQUE} index to a
-table used in a @code{MERGE} table and then to
-add a normal index on the @code{MERGE} table, the key order is
-different for the tables if there was an old key that was not unique in the
-table. This is because @code{ALTER TABLE} puts @code{UNIQUE} indexes before
-normal indexes to be able to detect duplicate keys as early as possible.
-@end itemize
-
-The following are known bugs in earlier versions of MySQL:
-
-@itemize @bullet
-@item
-In the following case you can get a core dump:
-
-@itemize @minus
-@item
-Delayed insert handler has pending inserts to a table.
-
-@item
-@code{LOCK TABLE} with @code{WRITE}.
-
-@item
-@code{FLUSH TABLES}.
-@end itemize
-
-@item
-Before MySQL Server 3.23.2, an @code{UPDATE} that updated a key with
-a @code{WHERE} on the same key may have failed because the key was used to
-search for records and the same row may have been found multiple times:
-
-@example
-UPDATE @var{tbl_name} SET KEY=KEY+1 WHERE KEY > 100;
-@end example
-
-A workaround is to use:
-
-@example
-UPDATE @var{tbl_name} SET KEY=KEY+1 WHERE KEY+0 > 100;
-@end example
-
-This works because MySQL Server does not use an index on expressions in
-the @code{WHERE} clause.
-
-@item
-Before MySQL Server 3.23, all numeric types were treated as
-fixed-point fields. That means that you had to specify how many decimals
-a floating-point field should have. All results were returned with the
-correct number of decimals.
-@end itemize
-
-For information about platform-specific bugs, see the installation and
-porting instructions in @ref{Operating System Specific Notes} and
-@ref{Porting}.
-
-
 @node Installing, Tutorial, Introduction, Top
 @chapter Installing MySQL
 
@@ -96314,6 +95852,7 @@
 * Query Issues::                Query-Related Issues
 * Optimizer Issues::            Optimizer-Related Issues
 * Table Definition Issues::     Table Definition-Related Issues
+* Bugs::                        Known Issues in MySQL
 @end menu
 
 This appendix lists some common problems and error messages that you may
@@ -98772,7 +98311,7 @@
 @end itemize
 
 
-@node Table Definition Issues,  , Optimizer Issues, Problems
+@node Table Definition Issues, Bugs, Optimizer Issues, Problems
 @appendixsec Table Definition-Related Issues
 
 
@@ -98923,6 +98462,419 @@
 
 @end itemize
 
+@node Bugs,  , Table Definition Issues, Problems
+@appendixsec Known Issues in MySQL
+
+@cindex bugs, known
+@cindex errors, known
+@cindex design, issues
+@cindex known errors
+
+This section is a list of the known issues in recent versions of MySQL.
+
+For information about platform-specific issues, see the installation and
+porting instructions in @ref{Operating System Specific Notes} and
+@ref{Porting}.
+
+
+@menu
+* Errors in 3.23::              Issues in MySQL 3.23 Fixed in a Later MySQL Version
+* Errors in 4.0::               Issues in 4.0 Fixed in a Later MySQL Version
+* Errors in 4.1::               Issues in 4.1 Fixed in a Later MySQL Version
+* Open bugs::                   Open Issues in MySQL
+@end menu
+
+@node Errors in 3.23, Errors in 4.0, Bugs, Bugs
+@appendixsubsec Issues in MySQL 3.23 Fixed in a Later MySQL Version
+
+The following known errors or bugs are not fixed in MySQL 3.23 because fixing
+them would involve changing a lot of code that could introduce other
+even worse bugs. The bugs are also classified as ``not fatal'' or
+``bearable.''
+
+@itemize @bullet
+@item
+Fixed in MySQL 4.0: Avoid using spaces at the end of column names because this can
+cause unexpected behavior. (Bug #4196)
+
+@item
+FIxed in MySQL 4.0.12: You can get a deadlock (hung thread) if you use @code{LOCK TABLE}
to lock
+multiple tables and then in the same connection use @code{DROP TABLE} to
+drop one of them while another thread is trying to lock it.  (To break the
+deadlock, you can use @code{KILL} to terminate any of the threads involved.)
+
+@item
+Fixed in MySQL 4.0.11: @code{SELECT MAX(key_column) FROM t1,t2,t3...} where one of the
tables are
+empty doesn't return @code{NULL} but instead returns the maximum value for the
+column.
+
+@item
+@code{DELETE FROM heap_table} without a @code{WHERE} clause doesn't work on
+a locked @code{HEAP} table.
+@end itemize
+
+@node Errors in 4.0, Errors in 4.1, Errors in 3.23, Bugs
+@appendixsubsec Issues in 4.0 Fixed in a Later MySQL Version
+
+The following known errors or bugs are not fixed in MySQL 4.0 because fixing
+them would involve changing a lot of code that could introduce other
+even worse bugs. The bugs are also classified as ``not fatal'' or
+``bearable.''
+
+@itemize @bullet
+@item
+Fixed in MySQL 4.1.10: Using @code{HAVING}, you can get a crash or wrong result if you
use an alias to
+a @code{RAND()} function. This will not be fixed
+in 4.0 because the fix may break compatability with some applications.
+
+@item
+Fixed in MySQL 4.1.1: In a @code{UNION}, the first @code{SELECT} determines the type,
+@code{max_length}, and @code{NULL} properties for the resulting
+columns.  
+
+@item
+Fixed in MySQL 4.1: In @code{DELETE} with many tables, you can't refer to tables to be
+deleted through an alias.
+
+@item
+Fixed in MySQL 4.1.2: You cannot mix @code{UNION ALL} and @code{UNION DISTINCT} in the
same query.
+If you use @code{ALL} for one @code{UNION}, it is used for all
+of them. 
+
+@item
+@code{FLUSH TABLES WITH READ LOCK} does not block @code{CREATE TABLE}, which
+may cause a problem with the binary log position when
+doing a full backup of tables and the binary log.
+
+@item
+Fixed in MySQL 4.1.8: @code{mysqldump --single-transaction --master-data} behaved like
+@code{mysqldump --master-data}, so the dump was a blocking one. 
+
+@item
+When using the @code{RPAD()} function (or any function adding spaces to the
+right) in a query that had to be resolved by using a temporary table, all
+resulting strings had rightmost spaces removed (i.e. @code{RPAD()} did not
+work).
+@end itemize
+
+@node Errors in 4.1, Open bugs, Errors in 4.0, Bugs
+@appendixsubsec Issues in 4.1 Fixed in a Later MySQL Version
+
+The following known errors or bugs are not fixed in MySQL 4.1 because fixing
+them would involve changing a lot of code that could introduce other
+even worse bugs. The bugs are also classified as ``not fatal'' or
+``bearable.''
+
+@itemize @bullet
+Fixed in 5.0.3: @code{VARCHAR} and @code{VARBINARY} did not remember end space.
+@end itemize
+
+@node Open bugs,  , Errors in 4.1, Bugs
+@appendixsubsec Open Issues in MySQL
+
+The following problems are known and fixing them is a high priority:
+
+@itemize @bullet
+
+@item
+If you compare a @code{NULL} value to a subquery using @code{ALL/ANY/SOME}
+and the subquery returns an empty result, the comparison might evaluate
+to the non-standard result of @code{NULL} rather than to @code{TRUE} or
+@code{FALSE}. This will be fixed in MySQL 5.1.
+
+@item
+Subquery optimization for @code{IN} is not as effective as for @code{=}.
+
+@item
+Even if you ude @code{lower_case_table_names=2} (which enables
+MySQL to remember the case used for databases and table names), MySQL
+does not remember the case used for database
+names for the function @code{DATABASE()} or within the various logs (on case-insensitive
systems).
+
+@item
+Dropping a @code{FOREIGN KEY} constraint doesn't work in replication because
+the constraint may have another name on the slave.
+
+@item
+@code{REPLACE} (and @code{LOAD DATA} with the @code{REPLACE} option) does not
+trigger @code{ON DELETE CASCADE}.
+
+@item
+@code{DISTINCT} with @code{ORDER BY} doesn't work inside @code{GROUP_CONCAT()}
+if you don't use all and only those columns that are in the
+@code{DISTINCT} list.
+
+@item
+If one user has a long-running transaction and another user drops a
+table that is updated in the transaction, there is small chance that the
+binary log may contain the @code{DROP TABLE} command before the table is
+used in the transaction itself.  We plan to fix this by
+having the @code{DROP TABLE} command wait until the table is not being used in any
+transaction.
+
+@item
+When inserting a big integer value (between 2^63 and 2^64@minus{}1) into a
+decimal or string column, it is inserted as a negative value because
+the number is evaluated in a signed integer context.
+
+@item
+@code{FLUSH TABLES WITH READ LOCK} does not block @code{COMMIT} if the server
+is running without binary logging, which may cause a problem (of consistency
+between tables) when doing a full backup.
+
+@item
+@code{ANALYZE TABLE} on a @code{BDB} table may in some cases make the table
+unusable until you restart @command{mysqld}.  If this happens, look for
+errors of the following form in the MySQL error file:
+
+@example
+001207 22:07:56  bdb:  log_flush: LSN past current end-of-log
+@end example
+
+@item
+Don't execute @code{ALTER TABLE} on a @code{BDB} table on which you are
+running multiple-statement transactions until all those transactions complete.
+(The transaction might be ignored.)
+
+@item
+@code{ANALYZE TABLE}, @code{OPTIMIZE TABLE}, and @code{REPAIR TABLE} may
+cause problems on tables for which you are using @code{INSERT DELAYED}.
+
+@item
+Performing @code{LOCK TABLE ...} and @code{FLUSH TABLES ...} doesn't
+guarantee that there isn't a half-finished transaction in progress on the
+table.
+
+@item
+@code{BDB} tables are relatively slow to open. If you have many @code{BDB} tables
+in a database, it takes a long time to use the @command{mysql} client on
+the database if you are not using the @code{-A} option or if you are using
+@code{rehash}. This is especially noticeable when you have a large table cache.
+
+@item
+Replication uses query-level logging: The master writes the executed
+queries to the binary log. This is a very fast, compact, and efficient
+logging method that works perfectly in most cases.
+
+It is
+possible for the data on the master and slave to become different if a
+query is designed in such a way that the data modification is
+non-deterministic (generally not a recommended practice, even outside of replication).
+
+For example:
+
+@itemize @minus
+@item
+@code{CREATE ... SELECT} or
+@code{INSERT ... SELECT}  statements that
+insert zero or @code{NULL} values into an @code{AUTO_INCREMENT} column.
+@item
+@code{DELETE} if you are
+deleting rows from a table that has foreign keys with @code{ON DELETE
+CASCADE} properties.
+@item
+@code{REPLACE ... SELECT},
+@code{INSERT IGNORE ... SELECT} if you have
+duplicate key values in the inserted data.
+@end itemize
+
+@strong{If and only if the preceding queries have no @code{ORDER BY}
+clause guaranteeing a deterministic order}.
+
+For example, for @code{INSERT ... SELECT} with no @code{ORDER
+BY}, the @code{SELECT} may return rows in a different order
+(which results in a row having different ranks, hence getting a
+different number in the @code{AUTO_INCREMENT} column),
+depending on the choices made by the optimizers on the master and
+slave. 
+
+A query is optimized differently on the master and slave only if:
+
+@itemize @minus
+@item
+The files used by the two queries are not exactly the same; for
+example, @code{OPTIMIZE TABLE} was run on the master tables and not on
+the slave tables. (To fix this, @code{OPTIMIZE TABLE}, @code{ANALYZE TABLE},
+and @code{REPAIR TABLE} are written to the binary log as of MySQL 4.1.1).
+@item
+The table is stored using a different storage engine on the master than
+on the slave. (It is possible to use different storage engines on the master
+and slave. For example, you can use @code{InnoDB} on the master,
+but @code{MyISAM} on the slave if the slave has less available disk
+space.)
+@item
+MySQL buffer sizes (@code{key_buffer_size}, and so on) are different on
+the master and slave.
+@item
+The master and slave run different MySQL versions, and the optimizer
+code differs between these versions.
+@end itemize
+
+This problem may also affect database restoration using
+@command{mysqlbinlog|mysql}.
+
+The easiest way to avoid this problem is to add an
+@code{ORDER BY} clause to
+the aforementioned non-deterministic queries to ensure that the rows are always
+stored or modified in the same order.
+
+In future MySQL versions, we will automatically add an @code{ORDER BY}
+clause when needed.
+
+@end itemize
+
+The following issues are known and will be fixed in due time:
+
+@itemize @bullet
+
+@item
+Log filenames are based on the server hostname (if you don't specify a
+filename with the startup option). You have to use options such as
+@code{--log-bin=@var{old_host_name}-bin} if you change your hostname to something
+else. Another option is to rename the old files to reflect your
+hostname change (if these are binary logs, you need to edit the
+binary log index file and fix the binlog names there as well). @xref{Server options}.
+
+@item
+@command{mysqlbinlog} does not delete temporary files left after a
+@code{LOAD DATA INFILE} command. @xref{mysqlbinlog,  , @command{mysqlbinlog}}.
+
+@item
+@code{RENAME} doesn't work with @code{TEMPORARY} tables or tables used in a
+@code{MERGE} table.
+
+@item
+Due to the way table definition files are stored, you cannot use
+character 255 (@code{CHAR(255)}) in table names, column names, or enumerations.
+This is scheduled to be fixed in version 5.1 when we implement new table
+definition format files.
+
+@item
+When using @code{SET CHARACTER SET}, you can't use translated
+characters in database, table, and column names.
+
+@item
+You can't use @samp{_} or @samp{%} with @code{ESCAPE} in @code{LIKE
+... ESCAPE}.
+
+@item
+If you have a @code{DECIMAL} column in which the same number is stored in
+different formats (for example, @code{+01.00}, @code{1.00}, @code{01.00}),
+@code{GROUP BY} may regard each value as a different value.
+
+@item
+You cannot build the server in another directory when using
+MIT-pthreads. Because this requires changes to MIT-pthreads, we are not
+likely to fix this. @xref{MIT-pthreads}.
+
+@item
+@code{BLOB} and @code{TEXT} values can't ``reliably'' be used in @code{GROUP
+BY}, @code{ORDER BY} or @code{DISTINCT}. Only the first
+@code{max_sort_length} bytes are used when comparing @code{BLOB} values in
+these cases.  The default value of @code{max_sort_length} value is 1024 and 
+can be changed at server startup time.  As of MySQL 4.0.3, it can be
+changed at runtime. For older versions, a workaround is to
+use a substring.  For example:
+
+@example
+SELECT DISTINCT LEFT(@var{blob_col},2048) FROM @var{tbl_name};
+@end example
+
+@item
+Numeric calculations are done with @code{BIGINT} or @code{DOUBLE} (both are
+normally 64 bits long). Which precision you get depends on the function.
+The general rule is that bit functions are performed with @code{BIGINT}
+precision, @code{IF} and @code{ELT()} with @code{BIGINT} or @code{DOUBLE}
+precision, and the rest with @code{DOUBLE} precision.  You should try to
+avoid using unsigned long long values if they resolve to be larger than
+63 bits (9223372036854775807) for anything other than bit fields.
+MySQL Server 4.0 has better @code{BIGINT} handling than 3.23.
+
+@item
+You can have up to 255 @code{ENUM} and @code{SET} columns in one table.
+
+@item
+In @code{MIN()}, @code{MAX()}, and other aggregate functions, MySQL
+currently compares @code{ENUM} and @code{SET} columns by their string
+value rather than by the string's relative position in the set.
+
+@item
+@command{mysqld_safe} redirects all messages from @command{mysqld} to the
+@command{mysqld} log.  One problem with this is that if you execute
+@command{mysqladmin refresh} to close and reopen the log,
+@code{stdout} and @code{stderr} are still redirected to the old log.
+If you use @code{--log} extensively, you should edit @command{mysqld_safe} to
+log to @file{@var{host_name}.err} instead of @file{@var{host_name}.log} so that you can
+easily reclaim the space for the old log by deleting it and
+executing @command{mysqladmin refresh}.
+
+@item
+In an @code{UPDATE} statement, columns are updated from left to right.  If
+you refer to an updated column, you get the updated value instead of the
+original value. For example, the following statement increments @code{KEY}
+by @code{2}, @strong{not} @code{1}:
+
+@example
+mysql> UPDATE @var{tbl_name} SET KEY=KEY+1,KEY=KEY+1;
+@end example
+
+@item
+You can refer to multiple temporary tables in the same query, but
+you cannot refer to any given temporary table more than once.
+For example, the following doesn't work:
+
+@example
+mysql> SELECT * FROM temp_table, temp_table AS t2;
+ERROR 1137: Can't reopen table: 'temp_table'
+@end example
+
+@item
+The optimizer may handle @code{DISTINCT} differently when you are using
+``hidden'' columns in a join than when you are not.  In a join, hidden
+columns are counted as part of the result (even if they are not shown),
+whereas in normal queries, hidden columns don't participate in the
+@code{DISTINCT} comparison.  We will probably change this in the future to
+never compare the hidden columns when executing @code{DISTINCT}.
+
+An example of this is:
+
+@example
+SELECT DISTINCT mp3id FROM band_downloads
+       WHERE userid = 9 ORDER BY id DESC;
+@end example
+
+and
+
+@example
+SELECT DISTINCT band_downloads.mp3id
+       FROM band_downloads,band_mp3
+       WHERE band_downloads.userid = 9
+       AND band_mp3.id = band_downloads.mp3id
+       ORDER BY band_downloads.id DESC;
+@end example
+
+In the second case, using MySQL Server 3.23.x, you may get two identical rows in
+the result set (because the values in the hidden @code{id} column may differ).
+
+Note that this happens only for queries where that do not have the
+@code{ORDER BY} columns in the result.
+
+@item
+If you execute a @code{PROCEDURE} on a query that returns an empty set,
+in some cases the @code{PROCEDURE} does not transform the columns.
+
+@item
+Creation of a table of type @code{MERGE} doesn't check whether the underlying
+tables are compatible types.
+
+@item
+If you use @code{ALTER TABLE} to add a @code{UNIQUE} index to a
+table used in a @code{MERGE} table and then add a normal index on the 
+@code{MERGE} table, the key order is
+different for the tables if there was an old, non-@code{UNIQUE} key in the
+table. This is because @code{ALTER TABLE} puts @code{UNIQUE} indexes before
+normal indexes to be able to detect duplicate keys as early as possible.
+@end itemize
 
 @node Credits, TODO, Problems, Top
 @appendix Credits
@@ -100260,7 +100212,7 @@
 
 @menu
 * News-5.0.7::                  Changes in release 5.0.7 (not released yet)
-* News-5.0.6::                  Changes in release 5.0.6 (to be released soon)
+* News-5.0.6::                  Changes in release 5.0.6 (not released yet)
 * News-5.0.5::                  Changes in release 5.0.5 (not released)
 * News-5.0.4::                  Changes in release 5.0.4 (16 Apr 2005)
 * News-5.0.3::                  Changes in release 5.0.3 (23 Mar 2005: Beta)