into  polly.(none):/home/kaa/src/opt/bug28837/my51-bug29131

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.

into  polly.(none):/home/kaa/src/opt/bug32241/my51-bug29131

checked for each record'

The problem was in incorrectly calculated length of the buffer used to
store a hexadecimal representation of an index map in
select_describe(). This could result in buffer overrun and stack
corruption under some circumstances.

Fixed by correcting the calculation.

into  polly.(none):/home/kaa/src/opt/bug30666/my51-bug29131

tables or more

The problem was that the optimizer used the join buffer in cases when
the result set is ordered by filesort. This resulted in the ORDER BY
clause being ignored, and the records being returned in the order
determined by the order of matching records in the last table in join.

Fixed by relaxing the condition in make_join_readinfo() to take
filesort-ordered result sets into account, not only index-ordered ones.

into  polly.(none):/home/kaa/src/opt/bug29131/my51-bug29131

doesn't recognize it
  
This is a 5.1 version of the patch.
  
Problem:
  
'log' and 'log_slow_queries' were "fixed" variables, i.e. they showed up
in SHOW VARIABLES, but could not be used in expressions like 
"select @@log". Also, using them in the SET statement produced an 
incorrect "unknown system variable" error.
  
Solution:

Since as of MySQL 5.1.12 one can enable or disable the general query log
or the slow query log at runtime by changing values of
general_log/slow_query_log, make 'log' and 'log_slow_queries" to be 
synonyms for 'general_log' and 'slow_query_log' respectively.  This 
makes expressions using the '@@var' syntax backward compatible with 
5.0 and SHOW VARIABLES output to be consistent with the SET statement.

doesn't recognize it

This is a 5.0 version of the patch, it will be null-merged to 5.1

Problem:

'log' and 'log_slow_queries' were "fixed" variables, i.e. they showed up
in SHOW VARIABLES, but could not be used in expressions like 
"select @@log". Also, using them in the SET statement produced an 
incorrect "unknown system variable" error.

Solution:

Make 'log' and 'log_slow_queries' read-only dynamic variables to make 
them available for use in expressions, and produce a correct error 
about the variable being read-only when used in the SET statement.

into  polly.(none):/home/kaa/src/opt/bug28550/my51-bug28550

  
Since, as of MySQL 5.0.15, CHAR() arguments larger than 255 are converted into multiple result bytes, a single CHAR() argument can now take up to 4 bytes. This patch fixes Item_func_char::fix_length_and_dec() to take this into account.
  
This patch also fixes a regression introduced by the patch for bug21513. As now we do not always have the 'name' member of Item set for Item_hex_string and Item_bin_string, an own print() method has been added to Item_hex_string so that it could correctly be printed by Item_func::print_args().

move 'table_collation' field filling outside of if(file) condition
because this field has 'OPEN_FRM_ONLY' attribute

into  mysql.com:/home/gluh/MySQL/Merge/5.1-opt

updated result files

into  mysql.com:/home/gluh/MySQL/Merge/5.1-opt

into  mysql.com:/home/gluh/MySQL/Merge/5.0-opt

issue an error if string has illegal characters

into  gleb.loc:/home/uchum/work/bk/5.1-opt

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

into  magare.gmz:/home/kgeorge/mysql/autopush/B31156-5.1-opt

  Fixed dbug macros usage errors

into  magare.gmz:/home/kgeorge/mysql/work/B31156-5.1-opt

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

into  magare.gmz:/home/kgeorge/mysql/autopush/B31440-5.1-opt

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

into  gleb.loc:/home/uchum/work/bk/5.1-opt

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

into  magare.gmz:/home/kgeorge/mysql/work/B31440-5.1-opt

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

into  mysql.com:/home/hf/work/31155/my51-31155

into  mysql.com:/home/hf/work/31155/my51-31155

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

into  mysql.com:/home/hf/work/31155/my51-31155

into  gleb.loc:/home/uchum/work/bk/5.1-opt

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

into  mysql.com:/home/gluh/MySQL/Merge/5.1-opt

Bug#30982 CHAR(..USING..) can return a not-well-formed string
Bug#30986 Character set introducer followed by a HEX string can return bad result
check_well_formed_result moved to Item from Item_str_func
fixed Item_func_char::val_str for proper ucs symbols converting
added check for well formed strings for correct conversion of constants with underscore
charset

The special case with NULL as a regular expression
was handled at prepare time. But in this special case
the item was not marked as fixed. This caused an assertion
at execution time.
Fixed my marking the item as fixed even when known to 
return NULL at prepare time.

                  precision > 0 && scale <= precision'.

A sign of a resulting item of the IFNULL function was not
updated and the maximal length of this result was calculated
improperly. Correct algorithm was copy&pasted from the IF
function implementation.