Initialized usable_keys from table->keys_in_use instead of ~0
in test_if_skip_sort_order(). It was possible that a disabled
index was used for sorting.
Version for 4.0.
It fixes two problems:
1. The cause of the bug was that we did not check the table version for
the HANDLER ... READ commands. We did not notice when a table was
replaced by a new one. This can happen during ALTER TABLE, REPAIR
TABLE, and OPTIMIZE TABLE (there might be more cases). I call the fix
for this problem "the primary bug fix".
2. mysql_ha_flush() was not always called with a locked LOCK_open.
Though the function comment clearly said it must.
I changed the code so that the locking is done when required. I call
the fix for this problem "the secondary fix".
Removed wrong fix for bug #14009 (use of abs() on null value causes problems with filesort)
Mark that add_time(), time_diff() and str_to_date() can return null values
Procedure analyse() redefines select's fields_list. setup_copy_fields() assumes
that fields_list is a part of all_fields_list. Because select have only
3 columns and analyse() redefines it to have 10 columns, int overrun in
setup_copy_fields() occurs and server goes to almost infinite loop.
Because fields_list used not only to send data ad fields types, it's wrong
to allow procedure redefine it. This patch separates select's fileds_list
and procedure's one. Now if procedure is present, copy of fields_list is
created in procedure_fields_list and it is used for sending data and fields.
Date field was declared as not null, thus expression 'datefield is null'
was always false. For SELECT special handling of such cases is used.
There 'datefield is null' converted to 'datefield eq "0000-00-00"'.
In mysql_update() before creation of select added remove_eq_conds() call.
It makes some optimization of conds and in particular performs conversion
from 'is null' to 'eq'.
Also remove_eq_conds() makes some evaluation of conds and if it founds that
conds is always false then update statement is not processed further.
All this allows to perform some update statements process faster due to
optimized conds, and not wasting resources if conds known to be false.
collation
By default constant strings in second parameter of date_time() have case
insensitive collation. Because of this expressions date_format(f,'%m') and
date_format(f,'%M') wrongly becomes equal, which results in choosing wrong
column to sort by.
Now if second parameter of date_format() is constant then it's collation is
changed to case sensitive.
VALUES() can only refer to table insert going to.
But Item_insert_value::fix_fields() were passing to it's arg full table list,
This results in finding second column which shouldn't be found, and
failing with error about ambiguous field.
Item_insert_value::fix_fields() now passes only first table of full table
list.
select distinct char(column) fails with utf8
ctype_utf8.result, ctype_utf8.test:
Adding test case
sql_yacc.yy:
Adding new syntax.
item_strfunc.h:
Fixing wrong max_length calculation.
Also, adding CHAR(x USING charset),
for easier migrating from 4.1 to 5.0,
according to Monty's suggestion.
DISTINCT wasn't optimized away and caused creation of tmp table in wrong
case. This result in integer overrun and running out of memory.
Fix backported from 4.1. Now if optimizer founds that in result be only 1
row it removes distinct.
