- Make send_row_on_empty_set() return FALSE when simplify_cond() has found out
that HAVING is always FALSE
re-committing to put the fix into 5.0 and 5.1
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.
The name resolution for correlated subqueries and HAVING clauses
failed to distinguish which of two was being performed when there
was a reference to an outer aliased field.
Fixed by adding the condition that HAVING clause name resulotion
is being performed.
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.
The optimization that uses a unique index to remove GROUP BY, did not
ensure that the index was actually used, thus violating the ORDER BY
that is impled by GROUP BY.
Fixed by replacing GROUP BY with ORDER BY if the GROUP BY clause contains
a unique index. In case GROUP BY ... ORDER BY null is used, GROUP BY is
simply removed.
SELECT statement itself returns empty.
As a result of this bug 'SELECT AGGREGATE_FUNCTION(fld) ... GROUP BY'
can return one row instead of an empty result set.
When GROUP BY only has fields of constant tables
(with a single row), the optimizer deletes the group_list.
After that we lose the information about whether we had an
GROUP BY statement. Though it's important
as SELECT min(x) from empty_table; and
SELECT min(x) from empty_table GROUP BY y; have to return
different results - the first query should return one row,
second - an empty result set.
So here we add the 'group_optimized_away' flag to remember this case
when GROUP BY exists in the query and is removed
by the optimizer, and check this flag in end_send_group()
When fields are inserted instead of * in the select list they were not marked
for check for the ONLY_FULL_GROUP_BY mode.
The Field_iterator_table::create_item() function now marks newly created
items for check when in the ONLY_FULL_GROUP_BY mode.
The setup_wild() and the insert_fields() functions now maintain the
cur_pos_in_select_list counter for the ONLY_FULL_GROUP_BY mode.
Currently in the ONLY_FULL_GROUP_BY mode no hidden fields are allowed in the
select list. To ensure this each expression in the select list is checked
to be a constant, an aggregate function or to occur in the GROUP BY list.
The last two requirements are wrong and doesn't allow valid expressions like
"MAX(b) - MIN(b)" or "a + 1" in a query with grouping by a.
The correct check implemented by the patch will ensure that:
any field reference in the [sub]expressions of the select list
is under an aggregate function or
is mentioned as member of the group list or
is an outer reference or
is part of the select list element that coincide with a grouping element.
The Item_field objects now can contain the position of the select list
expression which they belong to. The position is saved during the
field's Item_field::fix_fields() call.
The non_agg_fields list for non-aggregated fields is added to the SELECT_LEX
class. The SELECT_LEX::cur_pos_in_select_list now contains the position in the
select list of the expression being currently fixed.
When resolving unqualified name references MySQL was not
checking what is the item type for the reference. Thus
e.g a string literal item that has by convention a name
equal to its string value will also work as a reference to
a SELECT list item or a table field.
Fixed by allowing only Item_ref or Item_field to referenced by
(unqualified) name.
Currently SQL_BIG_RESULT is checked only at compile time.
However, additional optimizations may take place after
this check that change the sort method from 'filesort'
to sorting via index. As a result the actual plan
executed is not the one specified by the SQL_BIG_RESULT
hint. Similarly, there is no such test when executing
EXPLAIN, resulting in incorrect output.
The patch corrects the problem by testing for
SQL_BIG_RESULT both during the explain and execution
phases.
optimizer does not honor IGNORE INDEX
- Allow an index to be used for sorting the table
instead of filesort only if it is not disabled by
IGNORE INDEX.
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.
length.
When temporary field created for DATE(LEFT(column,8)) expression, max_length
value is taken from Item_date_typecast, and it is getting it from underlaid
Item_func_left and it's max_length is 8 in given expression. And all this
results in stripping last 2 digits.
To Item_date_typecast class added its own fix_length_and_dec() function
that sets max_length value to 10, which is proper for DATE field.
Added a test case for bug #11414.
sql_select.cc:
Fixed bug #11414: crash on Windows with some simple
GROUP BY queries.
It happened to an allocation of an array containing
0 Copy_field elements in setup_copy_fields.
The bug had been already fixed in 5.0.
Added a test case for bug #11295.
item_buff.cc:
Fixed bug #11295.
This a correction for the patch of bug #11088 that takes into
account a possible NULL values of the BLOB column.
Added a test case for bug #11385.
group_by.test:
Added a test case for bug #11385.
field.h:
Fixed bug #11385.
The bug was due to not defined method decimals for the class
Field_datetime.
- Print warning that says display width is not supported for datatype TIMESTAMP, if user tries to create a TIMESTAMP column with display width.
- Use display width for TIMESTAMP only in type_timestamp test to make sure warning is displayed correctly.
Added a test case for bug #8614.
sql_select.cc:
Fixed bug #8614.
SELECT DISTINCT ... GROUP BY 'const' must be equivalent to
SELECT ... GROUP BY 'const'.
Fixed bug #11088: a crash for queries with GROUP BY a BLOB column
+ COUNT(DISTINCT...) due to an attempt to allocate a too large
buffer for the BLOB field.
Now the size of the buffer is limited by max_sort_length.
group_by.test, group_by.result:
Added a test case for bug #11088.
Ensure that references in HAVING, ORDER BY or GROUP BY are calculated after fields in SELECT.
This will ensure that any reference to these has a valid value.
Generalized the code for split_sum_func()
In Item_ref::Item_ref set maybe_null (and other fields fix_fields sets) to be the
same as in (*ref), because Item_ref::fix_fields() will not be called. Previously
maybe_null was 0 always and this produced a bogus state where
maybe_null==0 && is_null() == true
which broke evaluation for some upper-level Items, like AND and OR.
