Added HA_NULL_IN_KEY to table flags to allow for nullable unique indexes
and added test to verify
ha_federated.h:
BUG #15133 "unique index with nullable value not accepted in federated table"
added HA_NULL_IN_KEY to table flags to allow for nullable unique indexes
federated.test:
BUG #15133 "unique index with nullable value not accepted in federated table"
New test to show that nullable unique indexes work
federated.result:
BUG #15133 "unique index with nullable value not accepted in federated table"
New results for new test
The Federated storage engine used Field methods that had arbitrary limits on
the amount of data they could process, which caused problems with data
over that limit (4K). By removing those Field methods and just using
features of the String class, we can avoid this problem.
Changed the error reporting (and a crash) when inserting data into a
MERGE table that has no underlying tables or no INSERT_METHOD specified
by reporting that it is read-only.
closing temp tables through end_thread
had a flaw in binlog-off branch of close_temporary_tables where
next table to close was reset via table->next
for (table= thd->temporary_tables; table; table= table->next)
which was wrong since the current table instance got destoyed at
close_temporary(table, 1);
The fix adapts binlog-on branch method to engage the loop's internal 'next' variable which holds table->next prior table's destoying.
a too large value": the bug was that if MySQL generated a value for an
auto_increment column, based on auto_increment_* variables, and this value
was bigger than the column's max possible value, then that max possible
value was inserted (after issuing a warning). But this didn't honour
auto_increment_* variables (and so could cause conflicts in a master-master
replication where one master is supposed to generated only even numbers,
and the other only odd numbers), so now we "round down" this max possible
value to honour auto_increment_* variables, before inserting it.
auto_increment breaks binlog":
if slave's table had a higher auto_increment counter than master's (even
though all rows of the two tables were identical), then in some cases,
REPLACE and INSERT ON DUPLICATE KEY UPDATE failed to replicate
statement-based (it inserted different values on slave from on master).
write_record() contained a "thd->next_insert_id=0" to force an adjustment
of thd->next_insert_id after the update or replacement. But it is this
assigment introduced indeterminism of the statement on the slave, thus
the bug. For ON DUPLICATE, we replace that assignment by a call to
handler::adjust_next_insert_id_after_explicit_value() which is deterministic
(does not depend on slave table's autoinc counter). For REPLACE, this
assignment can simply be removed (as REPLACE can't insert a number larger
than thd->next_insert_id).
We also move a too early restore_auto_increment() down to when we really know
that we can restore the value.
run at startup"
The server returned an error when trying to execute init-file with a
stored procedure that could return multiple result sets to the client.
A stored procedure can return multiple result sets if it contains
PREPARE, SELECT, SHOW and similar statements.
The fix is to set client_capabilites|=CLIENT_MULTI_RESULTS in
sql_parse.cc:handle_bootstrap(). There is no "client" really, so
nothing is ever sent. This makes init-file feature behave consistently:
the prepared statements that can be called directly in the init-file
can be used in a stored procedure too.
Re-committed the patch originally submitted by Per-Erik after review.
Two functions have different ideas of what a string should look like;
one of them reads memory it assumes the other one may have written.
And "if you assume ..."
We now use a more defensive variety of the assuming function, this fixes
a warning thrown by the valgrind tool.
invoker name
The bug was fixed similar to how context switch is handled in
Item_func_sp::execute_impl(): we store pointer to current
Name_resolution_context in Item_func_current_user class, and use
its Security_context in Item_func_current_user::fix_fields().
