Table comment: issue a warning(error in traditional mode) if length of comment > 60 symbols
Column comment: issue a warning(error in traditional mode) if length of comment > 255 symbols
Table 'comment' is changed from char* to LEX_STRING
It was hard to distinguish case, when one was unable to create trigger
on the table because trigger with same action time and event already
existed for this table, from the case, when one tried to create trigger
with name which was already occupied by some other trigger, since in
both these cases we emitted ER_TRG_ALREADY_EXISTS error and message.
Now we emit ER_NOT_SUPPORTED_YET error with appropriate additional
message in the first case. There is no sense in introducing separate
error for this situation since we plan to get rid of this limitation
eventually.
CHECK TABLE could complain about a fully intact spatial index.
A wrong comparison operator was used for table checking.
The result was that it checked for non-matching spatial keys.
This succeeded if at least two different keys were present,
but failed if only the matching key was present.
I fixed the key comparison.
sp_grant_privileges(), the function that GRANTs EXECUTE + ALTER privs on a SP,
did so creating a user-entry with not password; mysql_routine_grant() would then
write that "change" to the user-table.
Bug #18361: Triggers on mysql.user table cause server crash
Because they do not work, we do not allow creating triggers on tables
within the 'mysql' schema.
(They may be made to work and re-enabled at some later date, but not
in 5.0 or 5.1.)
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.
'SELECT DISTINCT a,b FROM t1' should not use temp table if there is unique
index (or primary key) on a.
There are a number of other similar cases that can be calculated without the
use of a temp table : multi-part unique indexes, primary keys or using GROUP BY
instead of DISTINCT.
When a GROUP BY/DISTINCT clause contains all key parts of a unique
index, then it is guaranteed that the fields of the clause will be
unique, therefore we can optimize away GROUP BY/DISTINCT altogether.
This optimization has two effects:
* there is no need to create a temporary table to compute the
GROUP/DISTINCT operation (or the temporary table will be smaller if only GROUP
is removed and DISTINCT stays or if DISTINCT is removed and GROUP BY stays)
* this causes the statement in effect to become updatable in Connector/Java
because the result set columns will be direct reference to the primary key of
the table (instead to the temporary table that it currently references).
Implemented a check that will optimize away GROUP BY/DISTINCT for queries like
the above.
Currently it will work only for single non-constant table in the FROM clause.
When building the UPDATE query to send to the remote server, the
federated storage engine built the query incorrectly if it was updating
a field to be NULL.
Thanks to Bjrn Steinbrink for an initial patch for the problem.