Bug#8367 "low log doesn't gives complete information about prepared
statements"
Implement status variables for prepared statements commands (a port of
the patch by Andrey Hristov).
See details in comments to the changed files.
No test case as there is no way to test slow log/general log in
mysqltest.
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'.
Added test case for bug #11283.
field.h, field.cc:
Fixed bug #11283: wrong conversion from varchar to decimal.
Added methods Field_string::val_decimal,
Field_varstring::val_decimal, Field_blob::val_decimal.
They are not inherited from the base class Field_longstr
anymore.
Added a teast case for bug #11284.
sql_select.cc:
Fixed bug #11284.
Optimization with empty inner table currently cannot be
used in the case of nested outer join.
Added a test case for bug #11285.
sql_select.cc:
Fixed bug #11285.
The problem occurred with Item_equal in an 'on expression'
that was evaluated to false.
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.
The problem was that when there was no MIN or MAX function, after finding the
group prefix based on the DISTINCT or GROUP BY attributes we did not search further
for a key in the group that satisfies the equi-join conditions on attributes that
follow the group attributes. Thus we ended up with the wrong rows, and subsequent
calls to select_cond->val_int() in evaluate_join_record() were filtering those
rows. Hence - the query result set was empty.
The problem occured both for GROUP BY queries without MIN/MAX and for queries
with DISTINCT (which were internally executed as GROUP BY queries).
