Error was emitted when one tried to select information from view which used
merge algorithm and which also had CONVERT_TZ() function in its select list.
This bug was caused by wrong assumption that global table list for view
which is handled using merge algorithm begins from tables belonging to
the main select of this view. Nowadays the above assumption is not true only
when one uses convert_tz() function in view's select list, but in future
other cases may be added (for example we may support merging of views
with subqueries in select list one day). Relying on this false assumption
led to the usage of wrong table list for field lookups and therefor errors.
With this fix we explicitly use pointer to the beginning of main select's
table list.
Simply exclude INFORMATION_SCHEMA from LOAD DATA FROM MASTER just like
we exclude the `mysql` database.
There's no test for this, because it requires an unfiltered 'LOAD DATA
FROM MASTER' which is too likely to cause chaos (such as when running
the test suite against an external server).
Make InnoDB option "loose", as the server might be
started with this option just to find out the test
is to be skipped in the configuration (bug#17359)
Now NDB is only initialized and started when the tests that are
being run will make use of it. The same thing is also done for the
slave databases and the instance manager.
After review from Magnus: Only take a snapshot of the data directories
that are in use.
The bug caused wrong result sets for union constructs of the form
(SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2.
For such queries order lists were concatenated and limit clause was
completely neglected.
Bug #15684: @@version_* are not all SELECTable
Added the appropriate information as read-only system variables, and
also removed some special-case handling of @@version along the way.
@@version_bdb was added, but isn't included in the test because it
depends on the presence of BDB.
This was a case of too much code. The --start-dirty option should act
just like --start-and-exit, except it skips the database initialization
step. Now it does, which means it picks up the options from the specified
test case.
The SQL standard doesn't allow to use in HAVING clause fields that are not
present in GROUP BY clause and not under any aggregate function in the HAVING
clause. However, mysql allows using such fields. This extension assume that
the non-grouping fields will have the same group-wise values. Otherwise, the
result will be unpredictable. This extension allowed in strict
MODE_ONLY_FULL_GROUP_BY sql mode results in misunderstanding of HAVING
capabilities.
The new error message ER_NON_GROUPING_FIELD_USED message is added. It says
"non-grouping field '%-.64s' is used in %-.64s clause". This message is
supposed to be used for reporting errors when some field is not found in the
GROUP BY clause but have to be present there. Use cases for this message are
this bug and when a field is present in a SELECT item list not under any
aggregate function and there is GROUP BY clause present which doesn't mention
that field. It renders the ER_WRONG_FIELD_WITH_GROUP error message obsolete as
being more descriptive.
The resolve_ref_in_select_and_group() function now reports the
ER_NON_GROUPING_FIELD_FOUND error if the strict mode is set and the field for
HAVING clause is found in the SELECT item list only.
Fix BUG#16814: "SHOW INNODB STATUS format error in LATEST FOREIGN KEY ERROR section"
Add a missing newline to the LAST FOREIGN KEY ERROR section in SHOW INNODB STATUS
output.
Fix BUG#18934: "InnoDB crashes when table uses column names like DB_ROW_ID".
Refuse tables that use reserved column names.
Fixes for Bug#12429: Replication tests fail: "Slave_IO_Running" (?) differs related to MySQL 4.1
and Bug#16920 rpl_deadlock_innodb fails in show slave status (reported for MySQL 5.1)
