Before this fix, the command SHOW ENGINE <name> STATUS would:
- print a warning if the engine name is unknown,
- proceed and implement the same behavior as SHOW ENGINE ALL STATUS,
and list the status of all the storage engines registered.
In particular, this behavior caused confusion about the command :
SHOW ENGINE MUTEX STATUS, which as a side effect would print the status
of the innodb engine when that engine is registered.
Also, before this fix, every time an unknown engine name was substituted by
the default engine (which happen unless SQL_MODE NO_ENGINE_SUBSTITUTION is
set), a malformed warning was raised.
For example, the command ALTER TABLE T1 ENGINE = X would print :
Warnings:
Error 1286 Unknown table engine 'X'
With this fix:
SHOW ENGINE <name> STATUS|LOGS|MUTEX
always fails with an error when the engine <name> is unknown.
For other commands, warnings about unknown engines are raised as:
Warnings:
Warning 1286 Unknown table engine 'X'
In other words, engine substitution never affect the SHOW ENGINE command,
since this would lead to very confusing results.
Do not consider SHOW commands slow queries, just because they don't use proper indexes.
This bug fix is not needed in 5.1, and the code changes will be null merged. However, the test cases will be propogated up to 5.1.
Set a flag when a SHOW command is parsed, and check it in log_slow_statement(). SHOW commands are not counted as slow queries, even if they use table scans.
Identifiers with embedded escape characters were not handled correctly by
some SHOW statements due to some old code that was doing some extra unescaping.
'conc_sys' test
Concurrent execution of SELECT involing at least two INFORMATION_SCHEMA
tables, DROP DATABASE statement and DROP TABLE statement could have
resulted in stalled connection for this SELECT statement.
The problem was that for the first query of a join there was a race
between select from I_S.TABLES and DROP DATABASE, and the error (no
such database) was prepared to be send to the client, but the join
processing was continued. On second query to I_S.COLUMNS there was a
race with DROP TABLE, but this error (no such table) was downgraded to
warning, and thd->net.report_error was reset. And so neither result
nor error was sent to the client.
The solution is to stop join processing once it is clear we are going
to report a error, and also to downgrade to warnings file system errors
like 'no such database' (unless we are in the 'SHOW' command), because
I_S is designed not to use locks and the query to I_S should not abort
if something is dropped in the middle.
No test case is provided since this bug is a result of a race, and is
timing dependant. But we test that plain SHOW TABLES and SHOW COLUMNS
give a error if there is no such database or a table respectively.
The problem was that we restored SQL_CACHE, SQL_NO_CACHE flags in SELECT
statement from internal structures based on value set later at runtime, not
the original value set by the user.
The solution is to remember that original value.
Under row-based replication, DELETE FROM will now always be
replicated as individual row deletions, while TRUNCATE TABLE will
always be replicated as a statement.
Rename mix_innodb_myisam_binlog-master.opt; when the test was moved to
separate stm/row test cases, the .opt were not moved along with it,
causing a 60-second test duration because of default lock timeout :-(
- Encoding itself, implemented as a charset
"filename". Originally planned to use '.'
as an escape character, but now changed to '@'
for two reasons: "ls" does not return
file names starting with '.' considering them
as a kind of hidden files; some platforms
do not allow several dots in a file name.
- replacing many calls of my_snprintf() and
strnxmov() to the new build_table_filename().
- Adding MY_APPEND_EXT mysys flag, to append
an extention rather that replace it.
- Replacing all numeric constants in fn_format
flag arguments to their mysys definitions, e.g.
MY_UNPACK_FILENAME,
- Predictability in several function/methods:
when a table name can appear with or withot .frm
extension. Some functions/methods were changed
so accept names strictly with .frm, other - strictly
without .frm extensions. Several DBUG_ASSERTs were
added to check whether an extension is passed.
Many files:
table name to file name encoding
mysql_priv.h:
Prototypes for new table name encoding tools.
ctype-utf8.c:
Implementing "filename" charset for
table name to file name encoding.
row0mysql.c:
Fixing table name prefix.
mf_format.c:
Adding MY_APPEND_EXT processing.
Many files:
Fixing tests.
my_sys.h:
Adding new flag to append rather than replace an extension.
m_ctype.h:
Adding "filename" charset definition.
according to the standard.
The idea is to use Field-classes to implement stored routines
variables. Also, we should provide facade to Item-hierarchy
by Item_field class (it is necessary, since SRVs take part
in expressions).
The patch fixes the following bugs:
- BUG#8702: Stored Procedures: No Error/Warning shown for inappropriate data
type matching;
- BUG#8768: Functions: For any unsigned data type, -ve values can be passed
and returned;
- BUG#8769: Functions: For Int datatypes, out of range values can be passed
and returned;
- BUG#9078: STORED PROCDURE: Decimal digits are not displayed when we use
DECIMAL datatype;
- BUG#9572: Stored procedures: variable type declarations ignored;
- BUG#12903: upper function does not work inside a function;
- BUG#13705: parameters to stored procedures are not verified;
- BUG#13808: ENUM type stored procedure parameter accepts non-enumerated
data;
- BUG#13909: Varchar Stored Procedure Parameter always BINARY string (ignores
CHARACTER SET);
- BUG#14161: Stored procedure cannot retrieve bigint unsigned;
- BUG#14188: BINARY variables have no 0x00 padding;
- BUG#15148: Stored procedure variables accept non-scalar values;
are not specified in an insert. Most of these changes are actually to
clean up the test suite to either specify defaults to avoid warnings,
or add the warnings to the results. Related to bug #5986.
This fixed a bug in prepared statements when used with outher joins
Fixed a bug in SUM(DISTINCT) when used with prepared statements.
Some safety fixes in test scripts to ensure that previous test failures shouldn't affect other tests
