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.
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.
Select_type in the EXPLAIN output for the query SELECT * FROM t1 was
'SIMPLE', while for the query SELECT * FROM v1, where the view v1
was defined as SELECT * FROM t1, the EXPLAIN output contained 'PRIMARY'
for the select_type column.
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'.
When the GROUP BY clause contains a column reference that can be resolved to
both an aliased column in the SELECT list, and to a column in the FROM clause,
the group column is resolved to the column in the FROM clause (for ANSI conformance).
However, it may be so that the user's intent is just the other way around, and he/she
gets the query results grouped by a completely different column than expexted.
This patch adds a warning in such cases that tells the user that there is potential
ambiguity in the group column.
sql/sql_select.cc
- Added a warning when a GROUP column is ambiguous due to that there is a
column reference with the same name both in the SELECT and FROM clauses.
In this case we resolve to the column in FROM clause and warn the user
of a possible ambiguity.
- More extensive comments.
- Changed the function to return bool instead of int (as in other places).
mysql-test/t/group_by.test
Added test for BUG#11211.
mysql-test/r/group_by.result
Added test for BUG#11211.
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.
