The MIN/MAX optimization cannot be applied to a subquery if its WHERE clause
contains a conjunctive condition depending on an outer reference.

The MIN/MAX optimizer code from the function opt_sum_query erroneously
did not take into account conjunctive conditions that did not depend on
any table, yet were not identified as constant items. These could be
items containing rand() or PS/SP parameters. These items are supposed
to be evaluated at the execution phase. That's why if such conditions
can be extracted from the WHERE condition the MIN/MAX optimization is
not applied as currently it is always done at the optimization phase.

(In 5.3 expensive subqueries are also evaluated only at the execution
phase. So, if a constant condition with such subquery can be extracted
from the WHERE clause the MIN/MAX optimization should not be applied 
in 5.3.)

IF an IN/ALL/SOME predicate with a constant left part is transformed
into an EXISTS subquery the resulting subquery should not be considered
uncacheable if the right part of the predicate is not uncacheable.

Backported the function dbug_print_item() from 5.3. The function is used
only for debugging.  
 

set to 'on' by default.

and 'derived_with_keys'. Now they are set on by default.

The problem was that optimization code did not take into account later feature when instad of NOT before BETWEEN it has negated flag into the Item_func_between inherited from Item_func_neg_opt. So optimizer tried process NOT BETWEEN as BETWEEN.

The patch just switches off the optimisation for NOT BETWEEN as it was before when NOT function was really used.

compilation error in mysys/my_getsystime.c fixed
some redundant code removed
sec_to_time, time_to_sec, from_unixtime, unix_timestamp, @@timestamp now
  use decimal, not double for numbers with a fractional part.
purge_master_logs_before_date() fixed
many bugs in corner cases fixed

mysys/my_getsystime.c:
  compilation failure fixed
sql/sql_parse.cc:
  don't cut corners. it backfires.

When we create temporary result table for UNION
incorrect max_length for YEAR field is used and
it leads to incorrect field value and incorrect
result string length as YEAR field value calculation
depends on field length.
The fix is to use underlying item max_length for
Item_sum_hybrid::max_length intialization.


mysql-test/r/func_group.result:
  test case
mysql-test/t/func_group.test:
  test case
sql/field.cc:
  added assert
sql/item_sum.cc:
  init Item_sum_hybrid::max_length with 
  use underlying item max_length for
  INT result type.

In the string context the MIN() and MAX() functions don't take
into account the unsignedness of the UNSIGNED BIGINT argument
column.

I.e.:
        CREATE TABLE t1 (a BIGINT UNSIGNED);
        INSERT INTO t1 VALUES (18446668621106209655);
        SELECT CONCAT(MAX(a)) FROM t1;

returns -75452603341961.


mysql-test/r/func_group.result:
  Test case for bug #11766094.
mysql-test/t/func_group.test:
  Test case for bug #11766094.
sql/item.cc:
  Bug #11766094 - 59132: MIN() AND MAX() REMOVE UNSIGNEDNESS
  
  The Item_cache_int::val_str() method has been modified to
  take into account the unsigned_flag value when converting
  data to string.

- Backport the testcase (the fix itself was included with the subquery optimizations backport)

Item_sum_max/Item_sum_min incorrectly set null_value flag and
attempt to get result in parent functions leads to crash.
This happens due to double evaluation of the function argumet.
First evaluation happens in the comparator and second one
happens in Item_cache::cache_value().
The fix is to introduce new Item_cache object which
holds result of the argument and use this cached value
as an argument of the comparator.

mysql-test/r/func_group.result:
  test case
mysql-test/t/func_group.test:
  test case
sql/item.cc:
  added assertion that ether we have some result or result is NULL.
sql/item_sum.cc:
  introduce new Item_cache object which
  holds result of the argument and use this cached value
  as an argument of the comparator.
sql/item_sum.h:
  introduce new Item_cache object which
  holds result of the argument and use this cached value
  as an argument of the comparator.

when there was one NULL value, AVG(DISTINCT) could forget about other values.
See commit comment of item_sum.cc.

mysql-test/r/func_group.result:
  before the code fix, both SELECTs would return NULL
sql/item_sum.cc:
  Assume we are executing "SELECT AVG([DISTINCT] some_field) FROM some_table".
  and some_field is the single field of some_table for simplicity.
  Each time a row is processed (evaluate_join_record()->
  end_send_group()->update_sum_func()) an aggregator is notified,
  which itself notifies an Item_sum_avg.
  Without DISTINCT, this Item_sum_avg immediately increments its
  internal "sum of values" and "count of values" (the latter being
  Item_sum_avg::count). The count is incremented only if the row's value
  is not NULL (in Item_sum_avg::add()), per AVG() semantices. This row's value
  is available in args[0] of Item_sum_avg ("args[0]" stands for
  "the first argument of the item": it's an Item_field which automatically
  receives the row's value when a row is read from the table).
  bool Item_sum_avg::add()
  {
    if (Item_sum_sum::add()) << calculates the sum (ignores NULL)
      return TRUE;
    if (!args[0]->null_value)<<if added value is not NULL
      count++;       <<increment "count"
    return FALSE;
  }
  and everything works.
  With DISTINCT, when a row is processed by evaluate_join_record(),
  Item_sum_avg does no immediate computation, rather stores
  the row's value in a tree (to throw the value away if it is a duplicate
  of previous value, otherwise to remember all
  distinct values). It's only when it's time to send the average to the
  user (at end of the query:
  sub_select(end_of_records=true)->end_send_group()->
  select_send->send_data()->Protocol::send_result_set_row()->
  Item::send()->Item_sum_avg->val_str()), that we iterate over the tree,
  compute the sum and count: for this, for each element of the tree,
  Item_sum_avg::add() is called and has the same two steps as before:
  * Item_sum_sum::add() updates the sum (finding the tree element's value
  correctly, and determining correctly its NULLness - look for "arg_is_null"
  in that function)
  * the "if (!args[0]->null_value)" test right after, breaks: it uses args[0],
  which isn't the tree's element but rather the value for the last row
  processed by evaluate_join_record(). So if that last row was NULL,
  "count" stays 0 for each row, and AVG() then returns NULL (count==0 =>
  NULL, per AVG() semantics).
  The fix is to let the aggregator tell whether the value
  it just saw was NULL. The aggregator knows where to get the info
  thanks to virtual functions. Item_sum_sum::add() now asks
  the aggregator. Item_sum_avg() also asks the aggregator
  and then knows it shouldn't increment "count".
sql/item_sum.h:
  Aggregator can now tell about value/NULLness of just-aggregated value

            == MYSQL_TYPE_LONGLONG

A MIN/MAX() function with a subquery as its argument could lead
to a debug assertion on debug builds or wrong data on release
ones.

The problem was a combination of the following factors:

- Item_sum_hybrid::fix_fields() might use the argument
(args[0]) to calculate 'hybrid_field_type' which was later used
to decide how the data should be sent to the client.

- Item_sum::make_field() might use the argument again to
calculate the field's type when sending result set metadata to
the client.

- The argument could be changed in between these two calls via
  Item::set_arg() leading to inconsistent metadata being
  reported.

Here is what was happening for the bug's test case:

1. Item_sum_hybrid::fix_fields() calculates hybrid_field_type
as MYSQL_TYPE_LONGLONG based on args[0] which is an
Item::SUBSELECT_ITEM at that time.

2. A temporary table is created to execute the
query. create_tmp_field_from_item() creates a Field_long object
according to the subselect's max_length.

3. The subselect item in Item_sum_hybrid is replaced by the
Item_field object referencing the newly created Field_long.

4. Item_sum::make_field() rightfully returns the
MYSQL_TYPE_LONG type when calculating the result set metadata.

5. When sending the actual data, Item::send() relies on the
virtual field_type() function which in our case returns
previously calculated hybrid_field_type == MYSQL_TYPE_LONGLONG.

It looks like the only solution is to never refer to the
argument's metadata after the result metadata has been
calculated in fix_fields(), since the argument itself may be
different by then. In this sense, Item_sum::make_field() should
never be used, because it may rely on the argument's metadata
and is only called after fix_fields(). The "default"
implementation in Item::make_field() should be used instead as
it relies only on field_type(), but not on the argument's type.

Fixed by removing Item_sum::make_field() so that the superclass
implementation Item::make_field() is always used.

mysql-test/r/func_group.result:
  Added a test case for bug #54465.
mysql-test/t/func_group.test:
  Added a test case for bug #54465.
sql/item_sum.cc:
  Removed Item_sum::make_field() so that the superclass
  implementation Item::make_field() is always used.
sql/item_sum.h:
  Removed Item_sum::make_field() so that the superclass
  implementation Item::make_field() is always used.

The Item_cache_datetime::val_str function wasn't taking into account that time
could be negative. This led to failed assertion.
Now Item_cache_datetime::val_str correctly converts negative time values
from integer to string representation.

mysql-test/r/func_group.result:
  Added a test case for the bug#56120.
mysql-test/t/func_group.test:
  Added a test case for the bug#56120.
sql/item.cc:
  Bug#56120: Failed assertion on MIX/MAX on negative time value
  Now Item_cache_datetime::val_str correctly converts negative time values
  from integer to string representation.

A typo in the Item_cache_datetime::val_str caused an assertion to fail on the
maximum time value.


mysql-test/r/func_group.result:
  A test case for the bug#55648.
mysql-test/t/func_group.test:
  A test case for the bug#55648.
sql/item.cc:
  Bug#55648: Server crash on MIX/MAX on maximum time value
  Corrected assertion.

MySQL manual describes values of the YEAR(2) field type as follows:
values 00 - 69 mean 2000 - 2069 years and values 70 - 99 mean 1970 - 1999
years. MIN/MAX and comparison functions was comparing them as int values
thus producing wrong result.

Now the Arg_comparator class is extended with compare_year function which
performs correct comparison of the YEAR type.
The Item_sum_hybrid class now uses Item_cache and Arg_comparator objects to
correctly calculate its value.
To allow Arg_comparator to use func_name() function for Item_func and Item_sum
objects the func_name declaration is moved to the Item_result_field class.
A helper function is_owner_equal_func is added to the Arg_comparator class.
It checks whether the Arg_comparator object owner is the <=> function or not.
A helper function setup is added to the Item_sum_hybrid class. It sets up
cache item and comparator.

mysql-test/r/func_group.result:
  Added a test case for the bug#43668.
mysql-test/t/func_group.test:
  Added a test case for the bug#43668.
sql/item.cc:
  Bug#43668: Wrong comparison and MIN/MAX for YEAR(2)
  Now Item_cache_int returns the type of cached item.
sql/item.h:
  Bug#43668: Wrong comparison and MIN/MAX for YEAR(2)
  To allow Arg_comparator to use func_name() function for Item_func and Item_sum
  objects the func_name declaration is moved to the Item_result_field class.
sql/item_cmpfunc.cc:
  Bug#43668: Wrong comparison and MIN/MAX for YEAR(2)
  The Arg_comparator class is extended with compare_year function which
  performs correct comparison of the YEAR type.
sql/item_cmpfunc.h:
  Bug#43668: Wrong comparison and MIN/MAX for YEAR(2)
  The year_as_datetime variable is added to the Arg_comparator class.
  It's set to TRUE when YEAR value should be converted to the
  YYYY-00-00 00:00:00 format for correct YEAR-DATETIME comparison.
sql/item_geofunc.cc:
  Bug#43668: Wrong comparison and MIN/MAX for YEAR(2)
  Item_func_spatial_rel::val_int chenged to use Arg_comparator's string
  buffers.
sql/item_subselect.h:
  Bug#43668: Wrong comparison and MIN/MAX for YEAR(2)
  Added an implementation of the virtual func_name function.
sql/item_sum.cc:
  Bug#43668: Wrong comparison and MIN/MAX for YEAR(2)
  The Item_sum_hybrid class now uses Item_cache and Arg_comparator objects to
  correctly calculate its value.
  A helper function setup is added to the Item_sum_hybrid class. It sets up
  cache item and comparator.
sql/item_sum.h:
  Bug#43668: Wrong comparison and MIN/MAX for YEAR(2)
  The Item_sum_hybrid class now uses Item_cache and Arg_comparator objects to
  correctly calculate its value.
  Added an implementation of the virtual func_name function.

            columns without where/group
                     
Simple SELECT with implicit grouping used to return many rows if
the query was ordered by the aggregated column in the SELECT
list. This was incorrect because queries with implicit grouping
should only return a single record.
                              
The problem was that when JOIN:exec() decided if execution needed
to handle grouping, it was assumed that sum_func_count==0 meant
that there were no aggregate functions in the query. This
assumption was not correct in JOIN::exec() because the aggregate
functions might have been optimized away during JOIN::optimize().
                  
The reason why queries without ordering behaved correctly was
that sum_func_count is only recalculated if the optimizer chooses
to use temporary tables (which it does in the ordered case).
Hence, non-ordered queries were correctly treated as grouped.
                  
The fix for this bug was to remove the assumption that
sum_func_count==0 means that there is no need for grouping. This
was done by introducing variable "bool implicit_grouping" in the
JOIN object.

mysql-test/r/func_group.result:
  Add test for BUG#47280
mysql-test/t/func_group.test:
  Add test for BUG#47280
sql/opt_sum.cc:
  Improve comment for opt_sum_query()
sql/sql_class.h:
  Add comment for variables in TMP_TABLE_PARAM
sql/sql_select.cc:
  Introduce and use variable implicit_grouping instead of (!group_list && sum_func_count) in places that need to test if grouping is required. Also added comments for: optimization of aggregate fields for implicitly grouped queries  (JOIN::optimize) and choice of end_select method (JOIN::execute)
sql/sql_select.h:
  Add variable implicit_grouping, which will be TRUE for queries that contain aggregate functions but no GROUP BY clause. Also added comment to sort_and_group variable.

Original commentary:

Bug #37348: Crash in or immediately after JOIN::make_sum_func_list
            
The optimizer pulls up aggregate functions which should be aggregated in
an outer select. At some point it may substitute such a function for a field
in the temporary table. The setup_copy_fields function doesn't take this
into account and may overrun the copy_field buffer.
            
Fixed by filtering out the fields referenced through the specialized
reference for aggregates (Item_aggregate_ref).
Added an assertion to make sure bugs that cause similar discrepancy 
don't go undetected.


mysql-test/r/func_group.result:
  Backport bug #37348 fix 5.1 --> 5.0.
mysql-test/t/func_group.test:
  Backport bug #37348 fix 5.1 --> 5.0.
sql/item.cc:
  Backport bug #37348 fix 5.1 --> 5.0.
sql/item.h:
  Backport bug #37348 fix 5.1 --> 5.0.
sql/sql_select.cc:
  Backport bug #37348 fix 5.1 --> 5.0.

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.

      
The optimizer pulls up aggregate functions which should be aggregated in
an outer select. At some point it may substitute such a function for a field
in the temporary table. The setup_copy_fields function doesn't take this
into account and may overrun the copy_field buffer.
      
Fixed by filtering out the fields referenced through the specialized
reference for aggregates (Item_aggregate_ref).
Added an assertion to make sure bugs that cause similar discrepancy 
don't go undetected.

mysql-test/r/func_group.result:
  Bug #37348: test case
mysql-test/t/func_group.test:
  Bug #37348: test case
sql/item.cc:
  Bug #37348: Added a way to distinguish Item_aggregate_ref from the other types of refs
sql/item.h:
  Bug #37348: Added a way to distinguish Item_aggregate_ref from the other types of refs
sql/sql_select.cc:
  Bug #37348: 
   - Don't consider copying field references
      seen through Item_aggregate_ref
   - check for discrepancies between the number of expected 
     fields that need copying and the actual fields copied.

                    returns wrong results

Casting AVG() to DECIMAL led to incorrect results when the arguments
had a non-DECIMAL type, because in this case
Item_sum_avg::val_decimal() performed the division by the number of
arguments twice.

Fixed by changing Item_sum_avg::val_decimal() to not rely on
Item_sum_sum::val_decimal(), i.e. calculate sum and divide using
DECIMAL arithmetics for DECIMAL arguments, and utilize val_real() with
subsequent conversion to DECIMAL otherwise.


mysql-test/r/func_group.result:
  Added a test case for bug #34512.
mysql-test/t/func_group.test:
  Added a test case for bug #34512.
sql/item_sum.cc:
  Do not use Item_sum_sum::val_decimal() in Item_sum_avg::val_decimal()
  because the first one, depending on the arguments type, may return
  either the sum of the arguments, or the average calculated by the
  virtual val_real() method of Item_sum_avg. Instead, do our own
  calculation based on the arguments type.

When resolving references we need to take into consideration
the view "fields" and allow qualified access to them.
Fixed by extending the reference resolution to process view
fields correctly.


mysql-test/r/func_group.result:
  Bug #33133: test case
mysql-test/t/func_group.test:
  Bug #33133: test case
sql/sql_base.cc:
  Bug #33133: allow qualified alias refs to view fields

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

  file .\opt_sum.cc, line
The optimizer pre-calculates the MIN/MAX values for queries like
 SELECT MIN(kp_k) WHERE kp_1 = const AND ... AND kp_k-1 = const
when there is a key over kp_1...kp_k
In doing so it was not checking correctly nullability and 
there was a superfluous assert(). 
Fixed by making sure that the field can be null before checking and
taking out the wrong assert().
.
Introduced a correct check for nullability 
The MIN(field) can return NULL when all the row values in the group
are NULL-able or if there were no rows.
Fixed the assertion to reflect the case when there are no rows.


mysql-test/r/func_group.result:
  Bug #30715: test case
mysql-test/t/func_group.test:
  Bug #30715: test case
sql/opt_sum.cc:
  Bug #30715: correct nullability check for MIN/MAX pre-calculation over index.

  Item_sum_distinct::setup(THD*): Assertion

There was an assertion to detect a bug in ROLLUP
implementation. However the assertion is not true
when used in a subquery context with non-cacheable
statements.
Fixed by turning the assertion to accepted case
(just like it's done for the other aggregate functions). 


mysql-test/r/func_group.result:
  Bug #31156: test case
mysql-test/t/func_group.test:
  Bug #31156: test case
sql/item_sum.cc:
  Bug #31156: make it OK to call setup() several times:
   done for (e.g.) scalar subquery

to NULL

For queries of the form SELECT MIN(key_part_k) FROM t1 
WHERE key_part_1 = const and ... and key_part_k-1 = const,
the opt_sum_query optimization tries to
use an index to substitute MIN/MAX functions with their values according
to the following rules:
1) Insert the minimum non-null values where the WHERE clause still matches, or
3) A row of nulls

However, the correct semantics requires that there is a third case 2)
such that a NULL value is substituted if there are only NULL values for 
key_part_k.

The patch modifies opt_sum_query() to handle this missing case.


mysql-test/r/func_group.result:
  Bug #27573: Correct result
mysql-test/t/func_group.test:
  Bug #27573: test case
sql/opt_sum.cc:
  Bug #27573:
  Added code that will try to read the
  first non-null value for a given complete-field prefix, second
  choice is to read the null, and lastly set the error code if no row
  is found.

Round the results of std() for some calls with double arguments
to avoid double math precision problems.

In func_group.test, round the results of std() for some calls, because Windows' sqrt() function appears to return fewer "significant" digits than the Unix implementations.
This is for bug #22555.


mysql-test/r/func_group.result:
  Round the results of std() for some calls, because Windows' sqrt() function appears to return fewer "significant" digits than the Unix implementations.
  This is for bug #22555.
mysql-test/t/func_group.test:
  Round the results of std() for some calls, because Windows' sqrt() function appears to return fewer "significant" digits than the Unix implementations.
  This is for bug #22555.

When only one row was present, the subtraction of nearly the same number 
resulted in catastropic cancellation, introducing an error in the 
VARIANCE calculation near 1e-15.  That was sqrt()ed to get STDDEV, the 
error was escallated to near 1e-8.  

The simple fix of testing for a row count of 1 and forcing that to yield 
0.0 is insufficient, as two rows of the same value should also have a
variance of 0.0, yet the error would be about the same.

So, this patch changes the formula that computes the VARIANCE to be one
that is not subject to catastrophic cancellation.

In addition, it now uses only (faster-than-decimal) floating point numbers
to calculate, and renders that to other types on demand.


mysql-test/r/func_group.result:
  Test that the bug is fixed, and that no unexpected behavior arises from the 
  changes.
mysql-test/t/func_group.test:
  Test that the bug is fixed, and that no unexpected behavior arises from the 
  changes.
sql/item_sum.cc:
  Serg's suggestion: Force all VARIANCE calculations to be done with floating-
  point types.  It's faster, and the SQL standard says we may implement these
  functions any way we want.
  
  Additionally, use a form of variance calculation that is not subject to 
  catastrophic cancellation.   
  http://static.flickr.com/108/311308512_5c4e1c0c3d_b.jpg
sql/item_sum.h:
  Remove unused members and add a comment describing the recurrence relation.

We use val_int() calls (followed by null_value check) to determine 
nullness in some Item_sum_count' and Item_sum_count_distinct' methods, 
as a side effect we get extra warnings raised in the val_int().
Fix: use is_null() instead.


mysql-test/r/func_group.result:
  Fix for bug #21976: Unnecessary warning with count(decimal)
    - test result.
mysql-test/t/func_group.test:
  Fix for bug #21976: Unnecessary warning with count(decimal)
    - test case.
sql/item.h:
  Fix for bug #21976: Unnecessary warning with count(decimal)
    - comment adjusted.
sql/item_sum.cc:
  Fix for bug #21976: Unnecessary warning with count(decimal)
    - use is_null() to determine nullness.

  merge fix : removed undeterministic warnings


mysql-test/r/func_gconcat.result:
  merge fix : removed undeterministic warnings
mysql-test/r/func_group.result:
  merge fix : removed undeterministic warnings
mysql-test/t/func_gconcat.test:
  merge fix : removed undeterministic warnings
mysql-test/t/func_group.test:
  merge fix : removed undeterministic warnings

 Item::val_xxx() may be called by the server several times at execute time 
 for a single query. Calls to val_xxx() may be very expensive and sometimes
 (count(distinct), sum(distinct), avg(distinct)) not possible.
 To avoid that problem the results of calculation for these aggregate 
 functions are cached so that val_xxx() methods just return the calculated 
 value for the second and subsequent calls.


mysql-test/r/func_group.result:
  Bug #23184: SELECT causes server crash
   - test case
mysql-test/t/func_group.test:
  Bug #23184: SELECT causes server crash
   - test case
sql/item_sum.cc:
  Bug #23184: SELECT causes server crash
   - caching of the aggregate function results so no need to recalculate at val_xxx()
sql/item_sum.h:
  Bug #23184: SELECT causes server crash
   - caching of the aggregate function results so no need to recalculate at val_xxx()

 Treat queries with no FROM and aggregate functions as normal queries,
so the aggregate function get correctly calculated as if there is 1 row. 
This means that they will be considered to have one row, so COUNT(*) will return
1 instead of 0. Other aggregates will behave in compatible manner.


mysql-test/r/func_gconcat.result:
  Bug #16792 query with subselect, join, and group not returning proper values
   - test case. Note how it improves the support for DUAL.
mysql-test/r/func_group.result:
  Bug #16792 query with subselect, join, and group not returning proper values
   - test case. Note how it improves the support for DUAL.
mysql-test/r/subselect.result:
  Bug #16792 query with subselect, join, and group not returning proper values
   - consequence of (SELECT MAX(<const>)) now returning <const> instead of 0
mysql-test/t/func_group.test:
  Bug #16792 query with subselect, join, and group not returning proper values
   - test case.
sql/opt_sum.cc:
  Bug #16792 query with subselect, join, and group not returning proper values
   - cannot do the optimization if the index is already opened by (say) UPDATE
     as it invloves opening reading and closing the index.
sql/sql_select.cc:
  Bug #16792 query with subselect, join, and group not returning proper values
   - Treat queries with no FROM and aggregate functions as normal queries,
  so the aggregate function get correctly calculated as if there is 1 row.

 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.

mysql-test/r/func_group.result:
  Added another test case for bug #18206.
mysql-test/t/func_group.test:
  Added another test case for bug #18206.