GitLab

if table has bit fields then uneven bits(if exist) are stored into null bits place.
So we need to copy null bits in case of uneven bit field presence.


mysql-test/r/type_bit.result:
  test result
mysql-test/t/type_bit.test:
  test case
sql/sql_select.cc:
  if table has bit fields then uneven bits(if exist) are stored into null bits place.
  So we need to copy null bits in case of uneven bit field presence.

ONLY_FULL_GROUP_BY

The check for non-aggregated columns in queries with aggregate function, but without
GROUP BY was treating all the parts of the query as if they are in the SELECT list.
Fixed by ignoring the non-aggregated fields in the WHERE clause.

mysql-test/r/func_group.result:
  Bug #39656: test case
mysql-test/t/func_group.test:
  Bug #39656: test case
sql/sql_select.cc:
  Bug #39656: ignore the new non-aggregated column refs in a WHERE
  by saving the state so far and then adding only the new values of the other
  parts of the bitmask.

fails after the first time
  
Two separate problems : 
  1. When flattening joins the linked list used for name resolution 
  (next_name_resolution_table) was not updated.
  Fixed by updating the pointers when extending the table list
  
  2. The items created by expanding a * (star) as a column reference
  were marked as fixed, but no cached table was assigned to them 
  (unlike what Item_field::fix_fields does).
  Fixed by assigning a cached table (so the re-preparation is done
  faster).
  
Note that the fix for #2 hides the fix for #1 in most cases
(except when a table reference cannot be cached).

mysql-test/r/sp.result:
  Bug #33811: test case
mysql-test/t/sp.test:
  Bug #33811: test case
sql/sql_base.cc:
  Bug #33811: cache the table for Item_fields created by expanding '*'
sql/sql_select.cc:
  Bug #33811: maintain a correct name resolution chain when
  flattening joins.

Server crashed during a sort order optimization
of a dependent subquery:

SELECT
    (SELECT t1.a FROM t1, t2
      WHERE t1.a = t2.b AND t2.a = t3.c
      ORDER BY t1.a)
  FROM t3;


Bitmap of tables, that the reference to outer table
column uses, in addition to the regular table bit
has the OUTER_REF_TABLE_BIT bit set.
The only_eq_ref_tables function traverses this map
bit by bit simultaneously with join->map2table list.
Obviously join->map2table never contains an entry
for the OUTER_REF_TABLE_BIT pseudo-table, so the
server crashed there.


The only_eq_ref_tables function has been modified
to traverse regular table bits only like the
update_depend_map function (resetting of the
OUTER_REF_TABLE_BIT there is enough, but
resetting of the whole set of PSEUDO_TABLE_BITS
is used there for sure).


mysql-test/r/order_by.result:
  Added test case for bug #39844.
mysql-test/t/order_by.test:
  Added test case for bug #39844.
sql/sql_select.cc:
  Bug #39844: Query Crash Mysql Server 5.0.67
  
  The only_eq_ref_tables function has been modified
  to traverse regular table bits only like the
  update_depend_map function (resetting of the
  OUTER_REF_TABLE_BIT there is enough, but
  resetting of the whole set of PSEUDO_TABLE_BITS
  is used there for sure).

            with COALESCE and JOIN

The server returned to a client the VARBINARY column type
instead of the DATE type for a result of the COALESCE,
IFNULL, IF, CASE, GREATEST or LEAST functions if that result
was filesorted in an anonymous temporary table during
the query execution.

For example:
  SELECT COALESCE(t1.date1, t2.date2) AS result
    FROM t1 JOIN t2 ON t1.id = t2.id ORDER BY result;


To create a column of various date/time types in a
temporary table the create_tmp_field_from_item() function
uses the Item::tmp_table_field_from_field_type() method
call. However, fields of the MYSQL_TYPE_NEWDATE type were
missed there, and the VARBINARY columns were created
by default.
Necessary condition has been added.


mysql-test/r/metadata.result:
  Added test case for bug #39283.
mysql-test/t/metadata.test:
  Added test case for bug #39283.
sql/sql_select.cc:
  Bug #39283: Date returned as VARBINARY to client for queries
              with COALESCE and JOIN
  
  To create a column of various date/time types in a
  temporary table the create_tmp_field_from_item() function
  uses the Item::tmp_table_field_from_field_type() method
  call. However, fields of the MYSQL_TYPE_NEWDATE type were
  missed there, and the VARBINARY columns were created
  by default.
  Necessary condition has been added.

used causes server crash.
      
When the loose index scan access method is used values of aggregated functions
are precomputed by it. Aggregation of such functions shouldn't be performed
in this case and functions should be treated as normal ones.
The create_tmp_table function wasn't taking this into account and this led to
a crash if a query has MIN/MAX aggregate functions and employs temporary table
and loose index scan.
Now the JOIN::exec and the create_tmp_table functions treat MIN/MAX aggregate
functions as normal ones when the loose index scan is used.


mysql-test/r/group_min_max.result:
  Added a test case for the bug#38195.
mysql-test/t/group_min_max.test:
  Added a test case for the bug#38195.
sql/sql_select.cc:
  Bug#38195: Incorrect handling of aggregate functions when loose index scan is
  used causes server crash.
  The JOIN::exec and the create_tmp_table functions treat MIN/MAX aggregate
  functions as normal ones when the loose index scan is used.

is used causes server crash.
  Revert the fix : unstable test case revealed by pushbuild

used causes server crash.

When the loose index scan access method is used values of aggregated functions
are precomputed by it. Aggregation of such functions shouldn't be performed
in this case and functions should be treated as normal ones.
The create_tmp_table function wasn't taking this into account and this led to
a crash if a query has MIN/MAX aggregate functions and employs temporary table
and loose index scan.
Now the JOIN::exec and the create_tmp_table functions treat MIN/MAX aggregate
functions as normal ones when the loose index scan is used.


mysql-test/r/group_min_max.result:
  Added a test case for the bug#38195.
mysql-test/t/group_min_max.test:
  Added a test case for the bug#38195.
sql/sql_select.cc:
  Bug#38195: Incorrect handling of aggregate functions when loose index scan is
  used causes server crash.
  Now the JOIN::exec and the create_tmp_table functions treat MIN/MAX aggregate
  functions as normal ones when the loose index scan is used.

Calling List<Cached_item>::delete_elements for the same list twice
caused a crash of the server in the function JOIN::cleaunup.
Ensured that delete_elements() in JOIN::cleanup would be called only once.


mysql-test/r/subselect.result:
  Added a test case for bug #38191.
mysql-test/t/subselect.test:
  Added a test case for bug #38191.
sql/sql_select.cc:
  Fixed bug #38191.
  Ensured that delete_elements() in JOIN::cleanup would be called only once.

                  
Range scan in descending order for c <= <col> <= c type of
ranges was ignoring the DESC flag.
However some engines like InnoDB have the primary key parts 
as a suffix for every secondary key.
When such primary key suffix is used for ordering ignoring 
the DESC is not valid.
But we generally would like to do this because it's faster.
            
Fixed by performing only reverse scan if the primary key is used.
Removed some dead code in the process.

mysql-test/r/innodb_mysql.result:
  Bug#37830 : test case
mysql-test/t/innodb_mysql.test:
  Bug#37830 : test case
sql/opt_range.cc:
  Bug#37830 : 
  - preserve and use used_key_parts to
    distinguish when a primary key suffix is used
  - removed some dead code
sql/opt_range.h:
  Bug#37830 : 
  - preserve used_key_parts
  - dead code removed
sql/sql_select.cc:
  Bug#37830 : Do only reverse order traversal
  if the primary key suffix is used.

- In QUICK_INDEX_MERGE_SELECT::read_keys_and_merge: when we got table->sort from Unique,
  tell init_read_record() not to use rr_from_cache() because a) rowids are already sorted
  and b) it might be that the the data is used by filesort(), which will need record rowids
  (which rr_from_cache() cannot provide).
- Fully de-initialize the table->sort read in QUICK_INDEX_MERGE_SELECT::get_next(). This fixes BUG#35477.
(bk trigger: file as fix for BUG#35478).

sql/filesort.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - make find_all_keys() use quick->get_next() instead of init_read_record(r)/r.read_record() calls
  - added dbug printout
sql/mysql_priv.h:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - Added parameter to init_read_record
sql/opt_range.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - In QUICK_INDEX_MERGE_SELECT::read_keys_and_merge: when we got table->sort from Unique,
    tell init_read_record() not to use rr_from_cache() because a) rowids are already sorted
    and b) it might be that the the data is used by filesort(), which will need record rowids
    (which rr_from_cache() cannot provide).
  - Fully de-initialize the table->sort read in QUICK_INDEX_MERGE_SELECT::get_next().
sql/records.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - Added disable_rr_cache parameter to init_read_record
  - Added comment
sql/sql_acl.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - Added parameter to init_read_record
sql/sql_delete.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - Added parameter to init_read_record
sql/sql_help.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - Added parameter to init_read_record
sql/sql_select.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - Added parameter to init_read_record
sql/sql_table.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - Added parameter to init_read_record
sql/sql_udf.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - Added parameter to init_read_record
sql/sql_update.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - Added parameter to init_read_record

   with dependent subqueries
An IN subquery is executed on EXPLAIN when it's not correlated.
If the subquery required a temporary table for its execution
not all the internal structures were restored from pointing to
the items of the temporary table to point back to the items of
the subquery.
Fixed by restoring the ref array when a temp tables were used in
executing the IN subquery during EXPLAIN EXTENDED.


mysql-test/r/subselect.result:
  Bug #36011: test case
mysql-test/t/subselect.test:
  Bug #36011: test case
sql/sql_select.cc:
  Bug #36011: restore the ref array after execution 
  when there were temp tables.

                 impossible WHERE/HAVING clause
                 (subselect_single_select_engine::exec).

Allocation and initialization of joined table list t1, t2... of
subqueries like:

    NOT IN (SELECT ... FROM t1,t2,... WHERE 0)

is optimized out, however server tries to traverse this list.


mysql-test/r/subselect3.result:
  Added test case for bug#36005.
mysql-test/t/subselect3.test:
  Added test case for bug#36005.
sql/sql_select.cc:
  Fixed bug#36005.
  
  1. JOIN::prepare initializes JOIN::table counter (actually a size
     of the JOIN::join_tab array) and sets it to a number of joined tables.
  
  2. The make_join_statistics function (when called from JOIN::optimize)
     allocates and fills the JOIN::join_tab array.
     However, when optimizing subselect has impossible (definite false)
     WHERE or HAVING clause, optimizer skips call to make_join_statistics
     and leaves JOIN::join_tab == NULL.
  
  3. subselect_single_select_engine::exec does traversal of the JOIN::join_tab
     array and the server dies because array is not allocated but array
     counter is greater than 0.
  
  The JOIN::optimize method has been modified to reset the JOIN::table
  counter to 0 in cause of impossible WHERE/HAVING clause.

- Backported the 5.1 DBUG to 5.0.
- Avoid memory cleanup race on Windows client for CTRL-C


client/mysql.cc:
  Bug#26243 mysql command line crash after control-c
  - On Windows, the sigint handler shouldn't call mysql_end
  because the main thread will do so automatically.
  - Remove unnecessary signal call from the sigint handler.
  - Call my_end with proper value.
dbug/dbug.c:
  Bug#26243 mysql command line crash after control-c
  - Backported the 5.1 DBUG library. The old version uses a non-thread 
  safe global variable 'static struct state *stack'.
dbug/factorial.c:
  Bug#26243 mysql command line crash after control-c
  - Backported the 5.1 DBUG library. The old version uses a non-thread 
  safe global variable 'static struct state *stack'.
dbug/user.r:
  Bug#26243 mysql command line crash after control-c
  - Backported the 5.1 DBUG library. The old version uses a non-thread 
  safe global variable 'static struct state *stack'.
include/my_dbug.h:
  Bug#26243 mysql command line crash after control-c
  - Backported the 5.1 DBUG library. The old version uses a non-thread 
  safe global variable 'static struct state *stack'.
libmysql/libmysql.c:
  Bug#26243 mysql command line crash after control-c
  - Update for new DBUG library.
myisam/mi_open.c:
  Bug#26243 mysql command line crash after control-c
  - Update for new DBUG library.
sql/ha_federated.cc:
  Bug#26243 mysql command line crash after control-c
  - Update for new DBUG library.
sql/ha_innodb.cc:
  Bug#26243 mysql command line crash after control-c
  - Update for new DBUG library.
sql/ha_myisammrg.cc:
  Bug#26243 mysql command line crash after control-c
  - Update for new DBUG library.
sql/item_cmpfunc.cc:
  Bug#26243 mysql command line crash after control-c
  - Update for new DBUG library.
sql/mysqld.cc:
  Bug#26243 mysql command line crash after control-c
  - Update for new DBUG library.
sql/net_serv.cc:
  Bug#26243 mysql command line crash after control-c
  - Update for new DBUG library.
sql/opt_range.cc:
  Bug#26243 mysql command line crash after control-c
  - Update for new DBUG library.
sql/set_var.cc:
  Bug#26243 mysql command line crash after control-c
  - Update for new DBUG library.
sql/slave.cc:
  Bug#26243 mysql command line crash after control-c
  - Update for new DBUG library.
sql/sql_cache.cc:
  Bug#26243 mysql command line crash after control-c
  - Update for new DBUG library.
sql/sql_select.cc:
  Bug#26243 mysql command line crash after control-c
  - Update for new DBUG library.
tests/mysql_client_test.c:
  Bug#26243 mysql command line crash after control-c
  - Update for new DBUG library.

Mixing aggregate functions and non-grouping columns is not allowed in the
ONLY_FULL_GROUP_BY mode. However in some cases the error wasn't thrown because
of insufficient check.

In order to check more thoroughly the new algorithm employs a list of outer
fields used in a sum function and a SELECT_LEX::full_group_by_flag.
Each non-outer field checked to find out whether it's aggregated or not and
the current select is marked accordingly.
All outer fields that are used under an aggregate function are added to the
Item_sum::outer_fields list and later checked by the Item_sum::check_sum_func
function.


mysql-test/t/group_by.test:
  Added a test case for the bug#27219: Aggregate functions in ORDER BY.
mysql-test/r/group_by.result:
  Added a test case for the bug#27219: Aggregate functions in ORDER BY.
sql/sql_select.cc:
  Bug#27219: Aggregate functions in ORDER BY.
  Implementation of new check for mixing non aggregated fields and aggregation
  function in the ONLY_FULL_GROUP_BY mode.
sql/sql_lex.cc:
  Bug#27219: Aggregate functions in ORDER BY.
  Initialization of the full_group_by_flag bitmap.
  SELECT_LEX::test_limit function doesn't reset ORDER BY
  clause anymore.
sql/sql_lex.h:
  Bug#27219: Aggregate functions in ORDER BY.
  The full_group_by_flag is added to the SELECT_LEX class.
sql/item_sum.h:
  Bug#27219: Aggregate functions in ORDER BY.
  The outer_fields list is added to the Item_sum class.
sql/mysql_priv.h:
  Bug#27219: Aggregate functions in ORDER BY.
  Defined a set of constants used in the new check for mixing non aggregated
  fields and sum functions in the ONLY_FULL_GROUP_BY_MODE.
sql/item_subselect.cc:
  Bug#27219: Aggregate functions in ORDER BY.
  The Item_in_subselect::select_in_like_transformer function now drops
  ORDER BY clause in all selects in a subquery.
sql/item_sum.cc:
  Bug#27219: Aggregate functions in ORDER BY.
  Now the Item_sum::check_sum_func function now checks whether fields in the
  outer_fields list are aggregated or not and marks selects accordingly.
sql/item.cc:
  Bug#27219: Aggregate functions in ORDER BY.
  Now the Item_field::fix_fields function checks whether the field is aggregated
  or not and marks its select_lex accordingly.

View definition as SELECT ... FROM DUAL WHERE ... has
valid syntax, but use of such view in SELECT or
SHOW CREATE VIEW syntax causes unexpected syntax error.

Server omits FROM DUAL clause when storing view body
string in a .frm file for further evaluation.
However, syntax of SELECT-witout-FROM query is more
restrictive than SELECT FROM DUAL syntax, and doesn't
allow the WHERE clause.

NOTE: this syntax difference is not documented.


View registration procedure has been modified to
preserve original structure of view's body.



mysql-test/r/view.result:
  Added test case for bug #35193.
mysql-test/t/view.test:
  Added test case for bug #35193.
sql/sql_select.cc:
  Fixed bug #35193.
  The st_select_lex::print function always omits FROM DUAL clause,
  even if original SELECT query has the WHERE clause.
  
  The mysql_register_view function uses this function to reconstruct
  a body of view's AS clause for further evaluation and stores that
  reconstructed clause in a .frm file.
  
  SELECT without FROM syntax is more restrictive than 
  SELECT FROM DUAL syntax: second one allows
  the WHERE clause, but first one is not.
  
  Use of this view in SELECT or SHOW CREATE VIEW queries
  causes unexpected syntax errors.
  
  
  The st_select_lex::print function has been modified to
  reconstruct FROM DUAL clause in queries when needed.
  
  
  TODO: Syntax difference is not documented and should be
  eliminated, however improvement of
  the SELECT-without-FROM syntax is not trivial and leads to
  significant modification of grammar file because of additional
  shift/reduce conflicts.

- Apply Eric Bergen's patch: in join_read_always_key(), move ha_index_init() call
  to before the late NULLs filtering code.
- Backport function comments from 6.0.


mysql-test/r/null_key.result:
  BUG#34945: "ref_or_null queries that are null_rejecting and have a null value crash mysql"
  - Testcase
mysql-test/t/null_key.test:
  BUG#34945: "ref_or_null queries that are null_rejecting and have a null value crash mysql"
  - Testcase
sql/sql_select.cc:
  BUG#34945: "ref_or_null queries that are null_rejecting and have a null value crash mysql"
  - Apply Eric Bergen's patch: in join_read_always_key(), move ha_index_init() call
    to before the late NULLs filtering code.
  - Backport function comments from 6.0

                  and Item_direct_ref constructor calls.

Order of ref->field_name and ref->table_name arguments
is of Item_ref and Item_direct_ref in the fix_inner_refs
function is inverted.


sql/sql_select.cc:
  Fixed bug #34830: mixed table and field names in Item_ref
                    and Item_direct_ref constructor calls.
  
  Order of ref->field_name and ref->table_name arguments
  is of Item_ref and Item_direct_ref in the fix_inner_refs
  function is inverted. See definitions:
  
    Item_ref(Name_resolution_context *context_arg, Item **item,
             const char *table_name_arg, const char *field_name_arg,
             bool alias_name_used_arg= FALSE)
    and
  
    Item_direct_ref(Name_resolution_context *context_arg, Item **item,
                    const char *table_name_arg,
                    const char *field_name_arg,
                    bool alias_name_used_arg= FALSE)

Problem is not about intervals and doesn't actually cause 'full table scan'.
We have an optimization for DISTINCT when we have
'DISTINCT field_from_first_join_table' we don't need to read all the
rows from the JOIN-ed table if we found one conforming row.
It stopped working in 5.0 as we return NESTED_LOOP_OK if we came upon
that case in the evaluate_join_record() and that doesn't break the
recordreading loop in sub_select().

Fixed by returning NESTED_LOOP_NO_MORE_ROWS in this case.


mysql-test/r/select.result:
  Bug #32942 now() - interval '7200' second is NOT pre-calculated, causing "full table scan".
  
  test result
mysql-test/t/select.test:
  Bug #32942 now() - interval '7200' second is NOT pre-calculated, causing "full table scan"
  
  test case
sql/sql_select.cc:
  Bug #32942 now() - interval '7200' second NOT pre-calculated, causing "full table scan"
  
  return NESTED_LOOP_NO_MORE_ROWS when we don't need to read rows from
  this table anymore

Two disjuncts containing equalities of the form key=const1 and key=const2 can
be merged into one if const1 is equal to const2. To check it the common 
collation of the constants were used rather than the collation of the field key.
For example when the default collation of the constants was cases insensitive
while the collation of the field was case sensitive, then two or-ed equality 
predicates key='b' and key='B' incorrectly were merged into one f='b'. As a 
result ref access was used instead of range access and wrong result sets were 
returned in many cases. 
Fixed the problem by comparing constant in the or-ed predicate with collation of
the key field.


mysql-test/r/range.result:
  Added a test case for bug #33833.
mysql-test/t/range.test:
  Added a test case for bug #33833.
sql/item.cc:
  Fixed bug #33833.
  Added the method eq_by_collation that compares two items almost as 
  the method Item::eq, but it rather enforces a given collation for
  the comparison.
sql/item.h:
  Fixed bug #33833.
  Added the method eq_by_collation that compares two items almost as 
  the method Item::eq, but it rather enforces a given collation for
  the comparison.

The problem occurred when one had a subquery that had an equality X=Y where 
Y referred to a named select list expression from the parent select. MySQL 
crashed when trying to use the X=Y equality for ref-based access. 

Fixed by allowing non-Item_field items in the described case.


mysql-test/r/subselect.result:
  BUG#33794 "MySQL crashes executing specific query"
  - Testcase
mysql-test/t/subselect.test:
  BUG#33794 "MySQL crashes executing specific query"
  - Testcase
sql/sql_select.cc:
  BUG#33794 "MySQL crashes executing specific query"
  get_store_key() assumed that if it got a reference
    t.key=Item_outer_ref(Item_direct_ref(x)) 
  then x was an Item_field object, which is not the case when one refers to a
  named select list expression out ot subquery.

Warnings elimination


sql/sql_select.cc:
  Bug#32848: Warnings elimination

There were two problems when inferring the correct field types resulting from
UNION queries.
- If the type is NULL for all corresponding fields in the UNION, the resulting 
  type would be NULL, while the type is BINARY(0) if there is just a single 
  SELECT NULL.
- If one SELECT in the UNION uses a subselect, a temporary table is created
  to represent the subselect, and the result type defaults to a STRING type,
  hiding the fact that the type was unknown(just a NULL value).
Fixed by remembering whenever a field was created from a NULL value and pass
type NULL to the type coercion if that is the case, and creating a string field
as result of UNION only if the type would otherwise be NULL.


mysql-test/r/union.result:
  Bug#32848: Test result
mysql-test/t/union.test:
  Bug#32848: Test case
sql/field.cc:
  Bug#32848: Initialization of new field
sql/field.h:
  Bug#32848: New member to record when a field was created from a NULL value.
sql/item.cc:
  Bug#32848: 
  A field created from a NULL value will submit NULL as type to the 
  type coercion procedure.
  If Item_type_holder has not inferred the correct type after processing all
  SELECTs in a UNION, a string field is created.
sql/sql_select.cc:
  Bug#32848: Recording when a field is created from a NULL value.

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.


mysql-test/r/innodb_mysql.result:
  Added a test case for bug #32815.
mysql-test/t/innodb_mysql.test:
  Added a test case for bug #32815.
sql/sql_select.cc:
  Fixed bug #32815.
  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.

sql/sql_select.cc:
  Fix compiler warning (probably harmless, wrong integer size)

Index lookup does not always guarantee that we can
simply remove the relevant conditions from the WHERE
clause. Reasons can be e.g. conversion errors, 
partial indexes etc. 
The optimizer was removing these parts of the WHERE 
condition without any further checking.
This leads to "false positives" when using indexes.
Fixed by checking the index reference conditions
(using WHERE) when using indexes with sub-queries.


mysql-test/r/subselect.result:
  Bug #30788: 
   - using where
   - test case
mysql-test/r/subselect3.result:
  Bug #30788: using where
mysql-test/t/subselect.test:
  Bug #30788: test case
sql/item.h:
  Bug #30788: 
   - Declare eq() method of Item_cache descendants : this is used in
   test_if_ref()
   - preserve the field that is being cached for type comparisions
sql/sql_select.cc:
  Bug #30788: Don't remove the WHERE when using index lookup 
  with subqueries.

  Additional stack check for the bug#31048.


sql/sql_select.cc:
  Additional stack check for the bug#31048.

Loose index scan does the grouping so the temp table does 
not need to do it, even when sorting.
Fixed by checking if the grouping is already done before
doing sorting and grouping in a temp table and do only 
sorting.


mysql-test/r/group_min_max.result:
  Bug #32268: test case
mysql-test/t/group_min_max.test:
  Bug #32268: test case
sql/sql_select.cc:
  Bug #32268: don't group in the temp table if already done

Server failed in assert() when we tried to create a DECIMAL() temp field
with a scale of more than the allowed 30. Now we limit the scale to the
allowed maximum. A truncation warning is thrown as necessary.


mysql-test/r/type_newdecimal.result:
  Show that out of range DECIMAL temp fields will no longer
  stop the server with an assert.
mysql-test/t/type_newdecimal.test:
  Show that out of range DECIMAL temp fields will no longer
  stop the server with an assert.
sql/sql_select.cc:
  When creating DECIMAL() temp field, ascertain we stay within allowed
  limits. If not, truncate and warn.

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.


mysql-test/r/explain.result:
  Added a test case for bug #32241.
mysql-test/t/explain.test:
  Added a test case for bug #32241.
sql/sql_select.cc:
  Corrected the buffer length calculation. Count one hex digit as 4 bits,
  not 8.

The columns in HAVING can reference the GROUP BY and 
SELECT columns. There can be "table" prefixes when
referencing these columns. And these "table" prefixes
in HAVING use the table alias if available.
This means that table aliases are subject to the same
storage rules as table names and are dependent on 
lower_case_table_names in the same way as the table 
names are.
Fixed by :
1. Treating table aliases as table names
and make them lowercase when printing out the SQL
statement for view persistence.
2. Using case insensitive comparison for table 
aliases when requested by lower_case_table_names


mysql-test/r/lowercase_view.result:
  Bug #31562: test case
mysql-test/t/lowercase_view.test:
  Bug #31562: test case
sql/item.cc:
  Bug #31562: lower_case_table_name contious comparison
  when searching in GROUP BY
sql/sql_base.cc:
  Bug #31562: lower_case_table_name contious comparison
  when searching in SELECT
sql/sql_select.cc:
  Bug #31562: treat table aliases as table names
  and make them lowercase when printing

UNIQUE (eq-ref) lookups result in table being considered as a "constant" table.
Queries that consist of only constant tables are processed in do_select() in a
special way that doesn't invoke evaluate_join_record(), and therefore doesn't
increase the counters join->examined_rows and join->thd->row_count.

The patch increases these counters in this special case.

NOTICE:
This behavior seems to contradict what the documentation says in Sect. 5.11.4:
"Queries handled by the query cache are not added to the slow query log, nor
are queries that would not benefit from the presence of an index because the
table has zero rows or one row."

No test case in 5.0 as issue shows only in slow query log, and other counters
can give subtly different values (with regard to counting in create_sort_index(),
synthetic rows in ROLLUP, etc.).


sql/sql_class.h:
  add documentation for some variables
sql/sql_select.cc:
  Don't forget const tables when counting read records!

The bug is a regression introduced by the fix for bug30596. The problem
was that in cases when groups in GROUP BY correspond to only one row,
and there is ORDER BY, the GROUP BY was removed and the ORDER BY
rewritten to ORDER BY <group_by_columns> without checking if the
columns in GROUP BY and ORDER BY are compatible. This led to
incorrect ordering of the result set as it was sorted using the
GROUP BY columns. Additionaly, the code discarded ASC/DESC modifiers
from ORDER BY even if its columns were compatible with the GROUP BY
ones.

This patch fixes the regression by checking if ORDER BY columns form a
prefix of the GROUP BY ones, and rewriting ORDER BY only in that case,
preserving the ASC/DESC modifiers. That check is sufficient, since the
GROUP BY columns contain a unique index.


mysql-test/r/group_by.result:
  Added a test case for bug #32202.
mysql-test/t/group_by.test:
  Added a test case for bug #32202.
sql/sql_select.cc:
  In cases when groups in GROUP BY correspond to only one row and there
  is ORDER BY, rewrite the query to ORDER BY <group_by_columns> only if
  the columns in ORDER BY and GROUP BY are compatible, i.e. either one
  forms a prefix for another.

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.


mysql-test/r/select.result:
  Added a test case for bug #30666.
mysql-test/t/select.test:
  Added a test case for bug #30666.
sql/sql_select.cc:
  Relaxed the condition to determine when the join buffer usage must be
  disabled. The condition is now true for cases when the result set is
  ordered by filesort, that is when 'join->order &&
  !join->skip_sort_order' is true.

The HAVING clause is subject to the same rules as the SELECT list
about using aggregated and non-aggregated columns.
But this was not enforced when processing implicit grouping from
using aggregate functions.
Fixed by performing the same checks for HAVING as for SELECT.


mysql-test/r/func_group.result:
  Bug #31794: test case
mysql-test/t/func_group.test:
  Bug #31794: test case
sql/sql_select.cc:
  Bug #31794: Check HAVING in addition to SELECT list

myisam/mi_write.c:
  type conversion fixed
myisam/sort.c:
  type conversion fixed
sql/ha_federated.cc:
  type conversion fixed
sql/ha_heap.cc:
  type conversion fixed
sql/ha_innodb.cc:
  type conversion fixed
sql/ha_myisam.cc:
  type conversion fixed
sql/opt_range.cc:
  type conversion fixed
sql/sql_map.cc:
  type conversion fixed
sql/sql_select.cc:
  type conversion fixed
sql/sql_update.cc:
  type conversion fixed

CPUs / Intel's ICC compile

The bug is a combination of two problems:

1. IA64/ICC MySQL binaries use glibc's qsort(), not the one in mysys.

2. The order relation implemented by join_tab_cmp() is not transitive,
i.e. it is possible to choose such a, b and c that (a < b) && (b < c)
but (c < a). This implies that result of a sort using the relation
implemented by join_tab_cmp() depends on the order in which
elements are compared, i.e. the result is implementation-specific. Since
choose_plan() uses qsort() to pre-sort the
join tables using join_tab_cmp() as a compare function, the results of
the sorting may vary depending on qsort() implementation.

It is neither possible nor important to implement a better ordering
algorithm in join_tab_cmp(). Therefore the only way to fix it is to
force our own qsort() to be used by renaming it to my_qsort(), so we don't depend
on linker to decide that.

This patch also "fixes" bug #20530: qsort redefinition violates the
standard.


include/my_sys.h:
  Renamed qsort() and qsort2() to my_qsort() and my_qsort2(). Since
  previously we relied on stdlib.h to provide a declaration for qsort(), a
  separate declaration for my_qsort() is now required.
libmysql/Makefile.shared:
  Added mf_qsort.c to libmysql, since my_lib.c now uses my_qsort() instead of qsort().
myisam/ft_boolean_search.c:
  Replaced qsort2() with my_qsort2().
myisam/ft_nlq_search.c:
  Replaced qsort2() with my_qsort2().
myisam/myisampack.c:
  Replaced qsort() with my_qsort().
myisam/sort.c:
  Replaced qsort2() with my_qsort2().
mysys/mf_keycache.c:
  Replaced qsort() with my_qsort().
mysys/mf_qsort.c:
  Renamed qsort() to my_qsort() and qsort2() to my_qsort2().
mysys/mf_sort.c:
  Replaced qsort2() with my_qsort2().
mysys/my_lib.c:
  Replaced qsort() with my_qsort().
mysys/queues.c:
  Replaced qsort2() with my_qsort2().
sql/item_cmpfunc.cc:
  Replaced qsort2() with my_qsort2().
sql/item_cmpfunc.h:
  Replaced qsort2() with my_qsort2().
sql/opt_range.cc:
  Replaced qsort() with my_qsort().
sql/records.cc:
  Replaced qsort() with my_qsort().
sql/sql_acl.cc:
  Replaced qsort() with my_qsort().
sql/sql_array.h:
  Replaced qsort() with my_qsort().
sql/sql_help.cc:
  Replaced qsort() with my_qsort().
sql/sql_select.cc:
  Replaced qsort() with my_qsort().
sql/examples/ha_tina.cc:
  Replaced qsort() with my_qsort().
sql/sql_table.cc:
  Replaced qsort() with my_qsort().

bitmap_is_set(table->write_set, fiel

Problem: creating a temporary table we allocate the group buffer if needed
followed by table bitmaps (see create_tmp_table()). Reserving less memory for 
the group buffer than actually needed (used) for values retrieval may lead 
to overlapping with followed bitmaps in the memory pool that in turn leads 
to unpredictable consequences.

As we use Item->max_length sometimes to calculate group buffer size,
it must be set to proper value. In this particular case 
Item_datetime_typecast::max_length is too small.

Another problem is that we use max_length to calculate the group buffer
key length for items represented as DATE/TIME fields which is superfluous.

Fix: set Item_datetime_typecast::max_length properly,
accurately calculate the group buffer key length for items 
represented as DATE/TIME fields in the buffer.


mysql-test/r/type_datetime.result:
  Fix for bug #31249: Assertion `!table || (!table->write_set || 
  bitmap_is_set(table->write_set, fiel
    - test result.
mysql-test/t/type_datetime.test:
  Fix for bug #31249: Assertion `!table || (!table->write_set || 
  bitmap_is_set(table->write_set, fiel
    - test case.
sql/item_timefunc.h:
  Fix for bug #31249: Assertion `!table || (!table->write_set || 
  bitmap_is_set(table->write_set, fiel
    - set Item_datetime_typecast::max_length properly.
sql/sql_select.cc:
  Fix for bug #31249: Assertion `!table || (!table->write_set || 
  bitmap_is_set(table->write_set, fiel
    - the group buffer key length for items represented as 
  DATE/TIME fields in the buffer should be calculated using
  the maximum pack length of such fields (== 8), using 
  max_length here is redundant.