* In a `WHERE' with an `ORDER BY' on fields from only one table, the
table is now preferred as first table in a multi-join.
* `HAVING' and `IS NULL' or `IS NOT NULL' now works.
* A group on one column and a sort on a group function (`SUM()',
`AVG()'...) didn't work together. Fixed.
* `mysqldump': Didn't send password to server.
Changes in release 3.19.4
-------------------------
* Fixed horrible locking bug when inserting in one thread and reading
in another thread.
* Fixed one-off decimal bug. 1.00 was output as 1.0.
* Added attribute `'Locked'' to process list as info if a query is
locked by another query.
* Fixed full magic timestamp. Timestamp length may now be 14, 12,
10, 8, 6, 4 or 2 bytes.
* Sort on some numeric functions could sort incorrectly on last
number.
* `IF(arg,syntax_error,syntax_error)' crashed.
* Added functions `CEILING()', `ROUND()', `EXP()', `LOG()' and
`SQRT()'.
* Enhanced `BETWEEN' to handle strings.
Changes in release 3.19.3
-------------------------
* Fixed `SELECT' with grouping on `BLOB' columns not to return
incorrect `BLOB' info. Grouping, sorting and distinct on `BLOB'
columns will not yet work as expected (probably it will group/sort
by the first 7 characters in the `BLOB'). Grouping on formulas
with a fixed string size (use `MID()' on a `BLOB') should work.
* When doing a full join (no direct keys) on multiple tables with
`BLOB' fields, the `BLOB' was garbage on output.
* Fixed `DISTINCT' with calculated columns.
Known errors and design deficiencies in MySQL
*********************************************
The following is known bugs in *MySQL* 3.23.22 that will be fixed in
the next release:
* Searching on part keys on BDB tables doesn't return all rows:
CREATE TABLE t1 (
user_id int(10) DEFAULT '0' NOT NULL,
name varchar(100),
phone varchar(100),
ref_email varchar(100) DEFAULT '' NOT NULL,
detail varchar(200),
PRIMARY KEY (user_id,ref_email)
)type=bdb;
INSERT INTO t1 VALUES (10292,'sanjeev','29153373','sansh777.hotmail.com','xxx'),(10292,'shirish','2333604','shirish.yahoo.com','ddsds'),(10292,'sonali','323232','sonali.bolly.com','filmstar');
select * from t1 where user_id=10292;
Other known problems:
* You cannot build in another directory when using MIT-pthreads.
Because this requires changes to MIT-pthreads, we are not likely
to fix this.
* `BLOB' values can't "reliably" be used in `GROUP BY' or `ORDER BY'
or `DISTINCT'. Only the first `max_sort_length' bytes (default
1024) are used when comparing `BLOB'bs in these cases. This can
be changed with the `-O max_sort_length' option to `mysqld'. A
workaround for most cases is to use a substring: `SELECT DISTINCT
LEFT(blob,2048) FROM tbl_name'.
* Calculation is done with `BIGINT' or `DOUBLE' (both are normally
64 bits long). It depends on the function which precision one
gets. The general rule is that bit functions are done with `BIGINT'
precision, `IF', and `ELT()' with `BIGINT' or `DOUBLE' precision
and the rest with `DOUBLE' precision. One should try to avoid
using bigger unsigned long long values than 63 bits
(9223372036854775807) for anything else than bit fields!
* All string columns, except `BLOB' and `TEXT' columns, automatically
have all trailing spaces removed when retrieved. For `CHAR' types
this is okay, and may be regarded as a feature according to ANSI
SQL92. The bug is that in *MySQL*, `VARCHAR' columns are treated
the same way.
* You can only have up to 255 `ENUM' and `SET' columns in one table.
* `safe_mysqld' re-directs all messages from `mysqld' to the
`mysqld' log. One problem with this is that if you execute
`mysqladmin refresh' to close and reopen the log, `stdout' and
`stderr' are still redirected to the old log. If you use `--log'
extensively, you should edit `safe_mysqld' to log to
`'hostname'.err' instead of `'hostname'.log' so you can easily
reclaim the space for the old log by deleting the old one and
executing `mysqladmin refresh'.
* In the `UPDATE' statement, columns are updated from left to right.
If you refer to a updated column, you will get the updated value
instead of the original value. For example:
mysql> UPDATE tbl_name SET KEY=KEY+1,KEY=KEY+1
will update `KEY' with `2' instead of with `1'.
* You can't use temporary tables more than once in the same query.
select * from temporary_table, temporary_table as t2;
* Because *MySQL* allows you to work with table types that doesn't
support transactions (and thus can't `rollback' data) some things
behaves a little different in *MySQL* than in other SQL servers:
(This is just to ensure that *MySQL* never need to do a rollback
for a SQL command). This may be a little akward at times as column
values must be checked in the application, but this will actually
give you a nice speed increase as it allows *MySQL* to do some
optimizations that otherwice would be very hard to do.
If you set a colum to a wrong value, *MySQL* will instead of doing
a rollback instead store the `best possible value' in the column.
* If you try to store a value outside of the range in a
numerical column, *MySQL* will instead store the smallest or
biggest possible value in the column.
* If you try to store a string, that doesn't start with a
number, into a numerical column *MySQL* will store 0 into it.
* If you try to to store `NULL' into a column that doesn't take
`NULL' values, `MySQL' will store 0 or `''' (empty string) in
it instead. (This behavour can however be changed with the
-DDONT_USE_DEFAULT_FIELDS compile option).
* *MySQL* allows you to store some wrong date values into
`DATE' and `DATETIME' columns. (Like 2000-02-31 or
2000-02-00). If the date is totally wrong, *MySQL* will
store the special 0000-00-00 date value in the column.
* If you set an `enum' to an not supported value, it will be
set to the error value 'empty string', with numeric value 0.
* If you execute a `PROCEDURE' on a query with returns an empty set
then in some cases the `PROCEDURE' will not transform the columns.
The following is known bugs in earlier versions of *MySQL*:
* You can get a hanged thread if you do a `DROP TABLE' on a table
that is one among many tables that is locked with `LOCK TABLES'.
* In the following case you can get a core dump:
1. Delayed insert handler has pending inserts to a table.
2. `LOCK table' with `WRITE'
3. `FLUSH TABLES'
* Before *MySQL* 3.23.2 an `UPDATE' that updated a key with a
`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:
UPDATE tbl_name SET KEY=KEY+1 WHERE KEY > 100;
A workaround is to use:
mysql> UPDATE tbl_name SET KEY=KEY+1 WHERE KEY+0 > 100;
This will work because *MySQL* will not use index on expressions in
the `WHERE' clause.
* Before *MySQL* 3.23, all numeric types where treated as fixed-point
fields. That means you had to specify how many decimals a
floating-point field shall have. All results were returned with
the correct number of decimals.
For platform-specific bugs, see the sections about compiling and
porting.
List of things we want to add to MySQL in the future (The TODO)
