into  mysql.com:/home/psergey/mysql-5.0-bug32198

- Make conditions like "date_col $CMP$ 'datetime-const'" range-sargable

with a fix for bug 32694. 

into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug27545

into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug32815

  
The problem was that when convert_constant_item is called for subqueries,
this happens when we already started executing the top-level query, and
the field argument of convert_constant_item pointed to a valid table row.
In turn convert_constant_item used the field buffer to compute the value
of its item argument. This copied the item's value into the field,
and made equalities with outer references always true.
  
The fix saves/restores the original field's value when it belongs to an
outer table.

Both arguments of the function NAME_CONST must be constant expressions.
This constraint is checked in the Item_name_const::fix_fields method. 
Yet if the argument of the function was not a constant expression no
error message was reported. As a result the client hanged waiting for a
response.
Now the function Item_name_const::fix_fields reports an error message
when any of the additional context conditions imposed on the function
NAME_CONST is not satisfied. 

The index (key_part_1, key_part-2) was erroneously considered as compatible
with the required ordering in the function test_test_if_order_by_key when 
a query with an ORDER BY clause contained a condition of the form
  key_part_1=const OR key_part_1 IS NULL 
and the order list contained only key_part_2. This happened because the value
of the const_key_parts field in the KEYUSE structure was not formed correctly
for the keys that could be used for ref_or_null access. 
This was fixed in the code of the update_ref_and_keys function.
The problem could not manifest itself for MyISAM databases because the
implementation of the keys_to_use_for_scanning() handler function always
returns an empty bitmap for the MyISAM engine.

into  mysql.com:/misc/mysql/31177/50-31177

additional fixes for BDB and correct assignment of both signed
and unsigned 64-bit data to unsigned system variables

into  dl145s.mysql.com:/data0/mhansson/my50-bug30234

Anti-patch. This patch undoes the previously pushed patch. It is 
null-merged in versions 5.1 and above since there the original 
patch is still desired.

additional fixes for 64-bit

into  mysql.com:/misc/mysql/31177/50-31177

into  mysql.com:/misc/mysql/32707/50-32707

into  mysql.com:/home/hf/work/mrg/my50-mrg

into  mysql.com:/home/hf/work/mrg/my50-mrg

into  mysql.com:/home/hf/work/mrg/my41-mrg

into  mysql.com:/misc/mysql/32180/50-32180

into  mysql.com:/home/hf/work/mrg/my50-mrg

into  mysql.com:/home/hf/work/mrg/my50-mrg

into  mysql.com:/home/hf/work/mrg/my50-mrg

into  mysql.com:/home/hf/work/mrg/my41-mrg

into  polly.(none):/home/kaa/src/opt/mysql-5.0-opt

filesort() uses file->estimate_rows_upper_bound() call to allocate
internal buffers. If this function returns a value smaller than
a number of row that will be returned later in find_all_keys(),
that can cause server crash.
Fixed by implementing ha_federated::estimate_rows_upper_bound() to
return maximum possible number of rows.
Present estimation for FEDERATED always returns 0 if the linked to the VIEW.

into  mysql.com:/misc/mysql/32707/50-32707

Default values of variables were not subject to upper/lower bounds
and step, while setting variables was. Bounds and step are also
applied to defaults now; defaults are corrected quietly, values
given by the user are corrected, and a correction-warning is thrown
as needed. Lastly, very large values could wrap around, starting
from 0 again. They are bounded at the maximum value for the
respective data-type now if no lower maximum is specified in the
variable's definition.

Denormalized DOUBLE-s can't be properly handled by old MIPS processors.
So we need to enable specific mode for them so IRIX will do use
software round to handle such numbers. 

server status wasn't properly sent to the client after the error
by the embedded server. Wasn't noticed before as one usually stopped
retrieving results after he gets an error.

Miscalculation in protocol-layer: size buffer correctly so
even really long error messages cannot overflow our buffer.

into  magare.gmz:/home/kgeorge/mysql/autopush/B30355-5.0-opt

into  gleb.loc:/work/bk/5.0-opt

into  magare.gmz:/home/kgeorge/mysql/autopush/B30355-5.0-opt

There's currently no way of knowing the determinicity of an UDF.
And the optimizer and the sequence() UDFs were making wrong
assumptions about what the is_const member means.
Plus there was no implementation of update_system_tables()
causing the optimizer to overwrite the information returned by
the <udf>_init function.

Fixed by equating the assumptions about the semantics of 
is_const and providing a implementation of update_used_tables().
Added a TODO item for the UDF API change needed to make a better 
implementation.

                  memory corruptions.

The right pointer field of the SEL_ARG structure was not
initialized in the constructor and sometimes that led to
server crashes.

There is no testcase because the bug occurs only when
uninitialized memory has particular values, which can't be
re-created in the test suite.

into  polly.(none):/home/kaa/src/opt/mysql-5.0-opt

self-join

When doing DELETE with self-join on a MyISAM or MERGE table, it could
happen that a record being retrieved in join_read_next_same() has
already been deleted by previous iterations. That caused the engine's
index_next_same() method to fail with HA_ERR_RECORD_DELETED error and
the whole DELETE query to be aborted with an error.

Fixed by suppressing the HA_ERR_RECORD_DELETED error in
hy_myisam::index_next_same() and ha_myisammrg::index_next_same(). Since
HA_ERR_RECORD_DELETED can only be returned by MyISAM, there is no point
in filtering this error in the SQL layer.

insert ... select.

The 5.0 manual page for mysql_insert_id() does not mention anything
about INSERT ... SELECT, though its current behavior is incosistent
with what the manual says about the plain INSERT.

Fixed by changing the AUTO_INCREMENT and mysql_insert_id() handling
logic in INSERT ... SELECT to be consistent with the INSERT behavior,
the manual, and the changes in 5.1 introduced by WL3146:


- mysql_insert_id() now returns the first automatically generated
AUTO_INCREMENT value that was successfully inserted by INSERT ... SELECT

-  if an INSERT ... SELECT statement is executed, and no automatically
generated value is successfully inserted, mysql_insert_id() now returns
the ID of the last inserted row.

into  magare.gmz:/home/kgeorge/mysql/autopush/B32036-5.0-opt

comment fixed as we truly need const_item to be 1 to mark
constant function