into  rakia.(none):/home/kgeorge/mysql/autopush/B11551-5.0-opt


mysql-test/r/view.result:
  Auto merged
mysql-test/t/view.test:
  Auto merged
sql/sql_view.cc:
  Auto merged

 
made DROP VIEW to continue on error and report an aggregated error 
 at its end. This makes it similar to DROP TABLE.


mysql-test/r/view.result:
  Bug #11551: Asymmetric + undocumented behaviour of DROP VIEW and DROP TABLE
   - test case
   - changed error message
mysql-test/t/view.test:
  Bug #11551: Asymmetric + undocumented behaviour of DROP VIEW and DROP TABLE
   - test case
sql/sql_view.cc:
  Bug #11551: Asymmetric + undocumented behaviour of DROP VIEW and DROP TABLE
   - made DROP VIEW to continue on error and report an aggregated error

into  macbook.gmz:/Users/kgeorge/mysql/work/B21080-5.0-opt


mysql-test/r/view.result:
  merge
mysql-test/t/view.test:
  merge

  When executing ALTER TABLE all the attributes of the view were overwritten.
  This is contrary to the user's expectations.
  So some of the view attributes are preserved now : namely security and 
  algorithm. This means that if they are not specified in ALTER VIEW
  their values are preserved from CREATE VIEW instead of being defaulted.


mysql-test/r/view.result:
  Bug #21080: ALTER VIEW makes user restate SQL SECURITY mode, and ALGORITHM
   - test suite
mysql-test/t/view.test:
  Bug #21080: ALTER VIEW makes user restate SQL SECURITY mode, and ALGORITHM
   - test suite
sql/sql_lex.h:
  Bug #21080: ALTER VIEW makes user restate SQL SECURITY mode, and ALGORITHM
   - must make create_view_suid a tristate : on/off/unspecified
sql/sql_view.cc:
  Bug #21080: ALTER VIEW makes user restate SQL SECURITY mode, and ALGORITHM
   - open the view to get it's attributes and put then as defaults 
     for ALTER VIEW
sql/sql_yacc.yy:
  Bug #21080: ALTER VIEW makes user restate SQL SECURITY mode, and ALGORITHM
   - must make create_view_suid a tristate : on/off/unspecified
sql/table.h:
  Bug #21080: ALTER VIEW makes user restate SQL SECURITY mode, and ALGORITHM
   - must make create_view_suid a tristate : on/off/unspecified

into  rakia.(none):/home/kgeorge/mysql/autopush/B21019-5.0-opt


sql/sql_select.cc:
  Auto merged

into  rakia.(none):/home/kgeorge/mysql/autopush/B20792-5.0-opt


sql/sql_select.cc:
  Auto merged

into  moonbone.local:/work/19862-bug-5.0-opt-mysql

  Post review changes for bug#19862.


sql/sql_select.cc:
  Post review changes for bug#19862.
sql/item_func.h:
  Post review changes for bug#19862.
sql/item_func.cc:
  Post review changes for bug#19862.
sql/item.h:
  Post review changes for bug#19862.

into  macbook.gmz:/Users/kgeorge/mysql/work/B20792-5.0-opt


mysql-test/r/subselect2.result:
  Auto merged
sql/sql_select.cc:
  Auto merged

When processing aggregate functions all tables values are reset
to NULLs at the end of each group. 
When doing that if there are no rows found for a group
the const tables must not be reset as they are not recalculated 
by do_select()/sub_select() for each group.


mysql-test/r/subselect2.result:
  * Bug #20792: Incorrect results from aggregate subquery
   - test suite for the bug. This is dependent on InnoDB despite
     the fact that the bug and the fix are not InnoDB specific.
     This is because of the table flag HA_NOT_EXACT_COUNT.
     When this flag is off (as in MyISAM) both t2 and t3 become of
     join type 'system' as they are estimated to have 1 record and
     and this statistics can be trusted (according to the absence of
     HA_NOT_EXACT_COUNT).
mysql-test/t/subselect2.test:
  * Bug #20792: Incorrect results from aggregate subquery
   - test suite for the bug
sql/sql_select.cc:
  * Bug #20792: Incorrect results from aggregate subquery
   - when clearing results if there are not rows found for group
     the const tables must not be reset as they are not recalculated
     for each group.

  Correct merge

into  macbook.gmz:/Users/kgeorge/mysql/work/B21019-5.0-opt


mysql-test/t/select.test:
  Auto merged
sql/sql_select.cc:
  Auto merged
mysql-test/r/select.result:
  SCCS merged

 When optimizing conditions like 'a = <some_val> OR a IS NULL' so that they're
 united into a single condition on the key and checked together the server must 
 check which value is the NULL value in a correct way : not only using ->is_null 
 but also check if the expression doesn't depend on any tables referenced in the 
 current statement. 
 This additional check must be performed because that optimization takes place 
 before the actual execution of the statement, so if the field was initialized 
 to NULL from a previous statement the optimization would be applied incorrectly.


mysql-test/r/select.result:
  Bug #21019: First result of SELECT COUNT(*) different than consecutive runs
   - test case
mysql-test/t/select.test:
  Bug #21019: First result of SELECT COUNT(*) different than consecutive runs
   - test case. 
     Note that ALTER TABLE is important here : it happens to
     leave the Field instance for t1.b set to NULL, witch is vital for
     demonstrating the problem fixed by this changeset.
sql/sql_select.cc:
  Bug #21019: First result of SELECT COUNT(*) different than consecutive runs
   - check whether a value is null taking into account its table dependency.

into  rakia.(none):/home/kgeorge/mysql/autopush/B21086-5.0-opt

into  moonbone.local:/work/19862-bug-5.0-opt-mysql


sql/item_func.h:
  Auto merged
sql/sql_select.cc:
  Auto merged

When there is no index defined filesort is used to sort the result of a
query. If there is a function in the select list and the result set should be
ordered by it's value then this function will be evaluated twice. First time to
get the value of the sort key and second time to send its value to a user.
This happens because filesort when sorts a table remembers only values of its
fields but not values of functions.
All functions are affected. But taking into account that SP and UDF functions
can be both expensive and non-deterministic a temporary table should be used 
to store their results and then sort it to avoid twice SP evaluation and to 
get a correct result.

If an expression referenced in an ORDER clause contains a SP or UDF 
function, force the use of a temporary table.

A new Item_processor function called func_type_checker_processor is added
to check whether the expression contains a function of a particular type.


mysql-test/t/udf.test:
  Added test case for bug#19862: Sort with filesort by function evaluates function twice
mysql-test/t/sp.test:
  Added test case for bug#19862: Sort with filesort by function evaluates function twice
mysql-test/r/sp.result:
  Added test case for bug#19862: Sort with filesort by function evaluates function twice
mysql-test/r/udf.result:
  Added test case for bug#19862: Sort with filesort by function evaluates function twice
sql/sql_select.cc:
  Fixed bug#19862: Sort with filesort by function evaluates function twice
  If an expression referenced in an ORDER clause contains a SP or UDF
  function, force the use of a temporary table.
sql/item_func.h:
  Fixed bug#19862: Sort with filesort by function evaluates function twice
  A new Item_processor function called func_type_checker_processor is added
  to check whether the expression contains a function of a particular type.
sql/item.h:
  Fixed bug#19862: Sort with filesort by function evaluates function twice
  A new Item_processor function called func_type_checker_processor is added
  to check whether the expression contains a function of a particular type.
sql/item_func.cc:
  Fixed bug#19862: Sort with filesort by function evaluates function twice
  A new Item_processor function called func_type_checker_processor is added
  to check whether the expression contains a function of a particular type.

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

  When executing INSERT over a view with calculated columns it was assuming all
  elements of the fields collection are actually Item_field instances.
  This may not be true when inserting into a view and that view has columns that are 
  such expressions that allow updating (like setting a collation for example).
  Corrected to access field information through the filed_for_view_update() function and 
  retrieve correctly the field info even for "update-friendly" non-Item_field items.


mysql-test/r/view.result:
  Bug #21086: server crashes when VIEW defined with a SELECT with COLLATE clause is called
   - test suite
mysql-test/t/view.test:
  Bug #21086: server crashes when VIEW defined with a SELECT with COLLATE clause is called
   - test suite
sql/item_strfunc.h:
  Bug #21086: server crashes when VIEW defined with a SELECT with COLLATE clause is called
   - obvious typo fixed
sql/sql_base.cc:
  Bug #21086: server crashes when VIEW defined with a SELECT with COLLATE clause is called
   - must access field information through the filed_for_view_update() function to retrieve
     correctly the field info even for "update-friendly" non-Item_field items.

into  rakia.(none):/home/kgeorge/mysql/autopush/B16712-5.0-opt


sql/item_sum.cc:
  Auto merged
sql/sql_select.cc:
  Auto merged

  when calculating GROUP_CONCAT all blob fields are transformed
  to varchar when making the temp table.
  However a varchar has at max 2 bytes for length. 
  This fix makes the conversion only for blobs whose max length 
  is below that limit. 
  Otherwise blob field is created by make_string_field() call.


mysql-test/r/func_gconcat.result:
  Bug#16712: group_concat returns odd srting insead of intended result
    * testsuite for the bug
mysql-test/t/func_gconcat.test:
  Bug#16712: group_concat returns odd srting insead of intended result
    * testsuite for the bug
sql/item_sum.cc:
  Bug#16712: group_concat returns odd srting insead of intended result
    * force blob->varchar conversion for small enough blobs only
sql/sql_select.cc:
  Bug#16712: group_concat returns odd srting insead of intended result
    * force blob->varchar conversion for small enough blobs only

a non-correlated single-row subquery over information schema.

The function get_all_tables filling all information schema
tables reset lex->sql_command to SQLCOM_SHOW_FIELDS. After
this the function could evaluate partial conditions related to
some columns. If these conditions contained a subquery over
information schema it led to a wrong evaluation and a wrong 
result set.
This bug was already fixed in 5.1.
This patch follows the way how it was done in 5.1 where
the value of lex->sql_command is set to SQLCOM_SHOW_FIELDS
in get_all_tables only for the calls of the function 
open_normal_and_derived_tables and is restored after these
calls.


mysql-test/r/information_schema.result:
  Added a test case for bug #21231.
mysql-test/t/information_schema.test:
  Added a test case for bug #21231.

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

subqueries on information schema that use MIN/MAX aggregation.

Execution of some correlated subqueries may set the value
of null_row to 1 for tables used in the subquery.
If the the subquery is on information schema it causes
rejection of any row for the following executions of
the subquery in the case when an optimization filtering
by some condition is applied.

The fix restores the value of the null_row flag for 
each execution of a subquery on information schema.


mysql-test/r/information_schema.result:
  Added a test case for bug #18925.
mysql-test/t/information_schema.test:
  Added a test case for bug #18925.
sql/sql_show.cc:
  Fixed bug #18925.
  Execution of some correlated subqueries may set the value
  of null_row to 1 for tables used in the subquery.
  If the the subquery is on information schema it causes
  rejection of any row for the following execitions of
  the subquery in the case when an optimization filtering
  by some condition is applied.
  
  The fix restores the value of the null_row flag for 
  each execution of a subquery on information schema.

into  macbook.mshome.net:/Users/kgeorge/mysql/work/B20466-5.0-opt


sql/sql_select.cc:
  Auto merged

into  rakia.(none):/home/kgeorge/mysql/autopush/B20868-5.0-opt

into  rakia.(none):/home/kgeorge/mysql/autopush/B20868-5.0-opt

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

into  rakia.(none):/home/kgeorge/mysql/autopush/B20868-5.0-opt

  Fixed typo.


sql/field.h:
  Fixed typo.

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


mysql-test/r/subselect.result:
  Manual merge
mysql-test/t/subselect.test:
  Manual merge

into  moonbone.local:/work/autopush/12185-bug-5.0-opt-mysql


mysql-test/r/create.result:
  Auto merged
mysql-test/t/innodb.test:
  Auto merged
sql/field.cc:
  Auto merged
sql/field.h:
  Auto merged
sql/item.cc:
  Auto merged
mysql-test/r/union.result:
  SCCS merged
mysql-test/t/union.test:
  SCCS merged

The Item::tmp_table_field_from_field_type() function creates Field_datetime
object instead of Field_timestamp object for timestamp field thus always
changing data type is a tmp table is used.

The Field_blob object constructor which is used in the 
Item::tmp_table_field_from_field_type() is always setting packlength field of
newly created blob to 4. This leads to changing fields data type for example
from the blob to the longblob if a temporary table is used.

The Item::make_string_field() function always converts Field_string objects 
to Field_varstring objects. This leads to changing data type from the 
char/binary to varchar/varbinary.

Added appropriate Field_timestamp object constructor for using in the 
Item::tmp_table_field_from_field_type() function.

Added Field_blob object constructor which sets pack length according to
max_length argument.

The Item::tmp_table_field_from_field_type() function now creates
Field_timestamp object for a timestamp field.

The Item_type_holder::display_length() now returns correct NULL length NULL
length. 

The Item::make_string_field() function now doesn't change Field_string to
Field_varstring in the case of Item_type_holder. 

The Item::tmp_table_field_from_field_type() function now uses the Field_blob
constructor which sets packlength according to max_length.


mysql-test/t/union.test:
  Added test case for bug#12185: Data type aggregation may produce wrong result
  Corrected test case after fix for bug#12185
mysql-test/t/innodb.test:
  Corrected test case after fix for bug#12185
mysql-test/r/union.result:
  Added test case for bug#12185: Data type aggregation may produce wrong result
   Corrected test case after fix for bug#12185
mysql-test/r/innodb.result:
  Corrected test case after fix for bug#12185
mysql-test/r/create.result:
  Corrected the test case after fixing bug#12185
sql/field.h:
  Fixed bug#12185: Data type aggregation may produce wrong result
  Added Field_blob object constructor which sets packlength according to
  max_length argument.
sql/item.cc:
  Fixed bug#12185: Data type aggregation may produce wrong result
  The Item::make_string_field() function now doesn't change Field_string to
  Field_varstring in the case of Item_type_holder.
  The Item::tmp_table_field_from_field_type() function now creates
  Field_timestamp object for a timestamp field.
  The Item::tmp_table_field_from_field_type() function now uses the Field_blob
  constructor which sets packlength according to max_length.
  The Item_type_holder::display_length() now returns correct NULL length NULL
  length.
sql/field.cc:
  Fixed bug#12185: Data type aggregation may produce wrong result
  Added appropriate Field_timestamp object constructor for using in the 
  Item::tmp_table_field_from_field_type() function.

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


sql/item_cmpfunc.cc:
  Auto merged
sql/item_cmpfunc.h:
  Auto merged
sql/item_subselect.cc:
  Auto merged
sql/item_subselect.h:
  Auto merged
sql/sql_parse.cc:
  Auto merged
mysql-test/r/subselect.result:
  Manual merge
mysql-test/t/subselect.test:
  Manual merge
sql/mysql_priv.h:
  Manual merge

  When making a place to store field values at the start of each group
  the real item (not the reference) must be used when deciding which column
  to copy.


mysql-test/r/group_by.result:
  Bug #20466: a view is mixing data when there's a trigger on the table
   - test suite for the bug
mysql-test/t/group_by.test:
  Bug #20466: a view is mixing data when there's a trigger on the table
   - test suite for the bug
sql/sql_select.cc:
  Bug #20466: a view is mixing data when there's a trigger on the table
   - deal correctly with references

into  rakia.(none):/home/kgeorge/mysql/autopush/B20868-5.0-opt

 An aggregate function reference was resolved incorrectly and
caused a crash in count_field_types.
 Must use real_item() to get to the real Item instance through
the reference


mysql-test/r/func_group.result:
  Bug #20868: Client connection is broken on SQL query error
   * test case for the bug
mysql-test/t/func_group.test:
  Bug #20868: Client connection is broken on SQL query error
   * test case for the bug
sql/sql_select.cc:
  Bug #20868: Client connection is broken on SQL query error
   * correctly resolve aggregate function references.

into  lamia.home:/home/tkatchaounov/autopush/5.0-bug-21007


client/mysql.cc:
  Auto merged
mysql-test/r/date_formats.result:
  Auto merged
mysql-test/r/func_str.result:
  Auto merged
mysql-test/t/date_formats.test:
  Auto merged
mysql-test/t/func_str.test:
  Auto merged
sql/item_strfunc.cc:
  Auto merged
sql/sql_class.cc:
  Auto merged
sql/time.cc:
  Auto merged

The problem was that store_top_level_join_columns() incorrectly assumed
that the left/right neighbor of a nested join table reference can be only
at the same level in the join tree.

The fix checks if the current nested join table reference has no immediate
left/right neighbor, and if so chooses the left/right neighbors of the
nearest upper level, where these references are != NULL.


mysql-test/r/group_min_max.result:
  Test for BUG#21007.
mysql-test/t/group_min_max.test:
  Test for BUG#21007.
sql/sql_base.cc:
  After computing and materializing the columns of all NATURAL joins in a FROM clause,
  the procedure store_top_level_join_columns() has to change the current natural join
  into a leaf table reference for name resolution. For this it needs to make the left
  neighbor point to the natural join table reference, and the natural join itself point
  to its left neighbor.
  
  This fix correctly determines the left/right neighbors of a table reference, even if
  the neghbors are at higher levels in the nested join tree. The rule is that if a table
  reference has no immediate left/right neighbors, we recursively pick the left/right
  neighbor of the level(s) above.