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.
thd->allow_sum_func was left 'true' after previous statement thus allowing
sum funcs to be present in conditions.
thd->allow_sum_func should be set to 0 for each query and each prepared
statement reinitialization. This is done in lex_start() and
reset_stmt_for_execute().
disabled if ref is built with a key from the updated table
Problem was in add_not_null_conds() optimization function.
It contains following code:
JOIN_TAB *referred_tab= not_null_item->field->table->reginfo.join_tab;
...
add_cond_and_fix(&referred_tab->select_cond, notnull);
For UPDATE described in bug report referred_tab is 0 and dereferencing it
crashes the server.
Don't produce data truncation warnings from within cp_buffer_from_ref(). This function
is only used to make index search tuples and data truncation that occurs here has no
relation with truncated values being saved into tables.
