Select with a "NULL NOT IN" condition containing complex
subselect from the same table as in the outer select failed
with an assertion.


The failure was caused by a concatenation of circumstances:
1) an inner select was optimized by make_join_statistics to use
   the QUICK_RANGE_SELECT access method (that implies an index
   scan of the table);
2) a subselect was independent (constant) from the outer select;
3) a condition was pushed down into inner select.

During the evaluation of a constant IN expression an optimizer
temporary changed the access method from index scan to table
scan, but an engine handler was already initialized for index
access by make_join_statistics. That caused an assertion.


Unnecessary index initialization has been removed from
the QUICK_RANGE_SELECT::init method (QUICK_RANGE_SELECT::reset
reinvokes this initialization).


mysql-test/r/subselect3.result:
  Added test case for bug #37894.
mysql-test/t/subselect3.test:
  Added test case for bug #37894.
sql/opt_range.cc:
  Bug #37894: Assertion in init_read_record_seq in handler.h line 1444
  
  Unnecessary index initialization has been removed from
  the QUICK_RANGE_SELECT::init method (QUICK_RANGE_SELECT::reset
  reinvokes this initialization).

            with COALESCE and JOIN

The server returned to a client the VARBINARY column type
instead of the DATE type for a result of the COALESCE,
IFNULL, IF, CASE, GREATEST or LEAST functions if that result
was filesorted in an anonymous temporary table during
the query execution.

For example:
  SELECT COALESCE(t1.date1, t2.date2) AS result
    FROM t1 JOIN t2 ON t1.id = t2.id ORDER BY result;


To create a column of various date/time types in a
temporary table the create_tmp_field_from_item() function
uses the Item::tmp_table_field_from_field_type() method
call. However, fields of the MYSQL_TYPE_NEWDATE type were
missed there, and the VARBINARY columns were created
by default.
Necessary condition has been added.


mysql-test/r/metadata.result:
  Added test case for bug #39283.
mysql-test/t/metadata.test:
  Added test case for bug #39283.
sql/sql_select.cc:
  Bug #39283: Date returned as VARBINARY to client for queries
              with COALESCE and JOIN
  
  To create a column of various date/time types in a
  temporary table the create_tmp_field_from_item() function
  uses the Item::tmp_table_field_from_field_type() method
  call. However, fields of the MYSQL_TYPE_NEWDATE type were
  missed there, and the VARBINARY columns were created
  by default.
  Necessary condition has been added.

 - fixed an unitialized memory read
 - fixed a compilation warning
 - added a suppression for FC9 x86_64

mysql-test/valgrind.supp:
  Bug #3214: added a suppression for FC9 x86_64
sql/item_func.cc:
  Bug #32124
   - fixed an unitialized memory read
   - fixed a compilation warning

 Fixed the handling of system variable retrieval
in prepared statements : added a cleanup method
that clears up the cache and restores the 
original scope of the variable (which is overwritten
at fix_fields()).

sql/item_func.cc:
  ug #32124: 
   - preserve the requested variable scope
   - clean up the cache and restore the variable
     scope for prepared statements.
sql/item_func.h:
  Bug #32124: preserve the requested variable scope

TRIGGERS.SQL_MODE, EVENTS.SQL_MODE, TRIGGERS.DEFINER:
field type is changed to VARCHAR.


mysql-test/r/information_schema.result:
  result fix
mysql-test/r/show_check.result:
  result fix
mysql-test/suite/funcs_1/r/is_columns_is.result:
  result fix
mysql-test/suite/funcs_1/r/is_events.result:
  result fix
mysql-test/suite/funcs_1/r/is_triggers.result:
  result fix
sql/sql_show.cc:
  TRIGGERS.SQL_MODE, EVENTS.SQL_MODE, TRIGGERS.DEFINER:
  field type is changed to VARCHAR.

The problem was that PACK_KEYS and MAX_ROWS clause in ALTER TABLE did not trigger
table reconstruction.
The fix is to rebuild a table if PACK_KEYS or MAX_ROWS are specified.


mysql-test/r/alter_table.result:
  test result
mysql-test/t/alter_table.test:
  test case
sql/sql_table.cc:
  The problem was that PACK_KEYS and MAX_ROWS clause in ALTER TABLE did not trigger
  table reconstruction.
  The fix is to rebuild a table if PACK_KEYS or MAX_ROWS are specified.

Hide "Table doesn't exist" errors if the table belongs to a merge table.


mysql-test/r/merge.result:
  result fix
mysql-test/t/merge.test:
  test case
sql/sql_base.cc:
  Hide "Table doesn't exist" errors if the table belongs to a merge table.

The problem: table_open_method is not calculated properly if '*' is used in 'select'
The fix: added table_open_method calculation for such case


mysql-test/r/information_schema.result:
  test result
mysql-test/t/information_schema.test:
  test case
sql/sql_show.cc:
  The problem: table_open_method is not calculated properly if '*' is used in 'select'
  The fix: added table_open_method calculation for such case

                  
The code to get read the value of a system variable was extracting its value 
on PREPARE stage and was substituting the value (as a constant) into the parse tree.
Note that this must be a reversible transformation, i.e. it must be reversed before
each re-execution.
Unfortunately this cannot be reliably done using the current code, because there are
other non-reversible source tree transformations that can interfere with this
reversible transformation.
Fixed by not resolving the value at PREPARE, but at EXECUTE (as the rest of the 
functions operate). Added a cache of the value (so that it's constant throughout
the execution of the query). Note that the cache also caches NULL values.
Updated an obsolete related test suite (variables-big) and the code to test the 
result type of system variables (as per bug 74).

mysql-test/extra/rpl_tests/rpl_insert_id.test:
  Bug #32124: removed ambiguous testcase
mysql-test/r/innodb_data_home_dir_basic.result:
  Bug #32124: fixed wrong test case
mysql-test/r/innodb_flush_method_basic.result:
  Bug #32124: fixed wrong test case
mysql-test/r/ps_11bugs.result:
  Bug #32124: test case
mysql-test/r/ssl_capath_basic.result:
  Bug #32124: fixed wrong test case
mysql-test/r/ssl_cipher_basic.result:
  Bug #32124: fixed wrong test case
mysql-test/r/variables.result:
  Bug #32124: system vars are shown as such in EXPLAIN EXTENDED, not as constants.
mysql-test/suite/rpl/r/rpl_insert_id.result:
  Bug #32124: removed ambiguous testcase
mysql-test/t/ps_11bugs.test:
  Bug #32124: test case
sql/item.cc:
  Bug #32124: placed the code to convert string to longlong or double 
  to a function (so that it can be reused)
sql/item.h:
  Bug #32124: placed the code to convert string to longlong or double 
  to a function (so that it can be reused)
sql/item_func.cc:
  Bug #32124: moved the evaluation of system variables at runtime (val_xxx).
sql/item_func.h:
  Bug #32124: moved the evaluation of system variables at runtime (val_xxx).
sql/set_var.cc:
  Bug #32124: removed the code that calculated the system variable's value 
  at PREPARE
sql/set_var.h:
  Bug #32124: removed the code that calculated the system variable's value 
  at PREPARE
tests/mysql_client_test.c:
  Bug #32124 : removed the reading of the system variable, because its max
  length is depended on the system charset and client charset and can't be
  easily calculated.

ha_statistic_increment for rpl_temporary

Problem: in some cases master send a special event to reconnecting
slave to keep slave's temporary tables (see #17284) and they still 
have references to the "old" SQL slave thread and use them to access
thread's data.

Fix: set temporary tables thread references to the actual SQL slave
thread in such cases.


mysql-test/suite/rpl/t/disabled.def:
  Fix for bug#38269: pushbuild gives valgrind error in 
  ha_statistic_increment for rpl_temporary
    - rpl_temporary test enabled.
sql/log_event.cc:
  Fix for bug#38269: pushbuild gives valgrind error in 
  ha_statistic_increment for rpl_temporary
    - if we keep slave's temporary tables after reconnect,
  set their thread pointers (->in_use) to the current SQL thread.

warnings)

Before this fix, several places in the code would raise a warning with an
error code 0, making it impossible for a stored procedure, a connector,
or a client application to trigger logic to handle the warning.
Also, the warning text was hard coded, and therefore not translated.

With this fix, new errors numbers have been created to represent these
warnings, and the warning text is coded in the errmsg.txt file.

so that if the substitution contains single-quotes, the program will fail.

Adds --general-log-file, --slow-query-log-file command-
line options to match system variables of the same names.

Deprecates --log, --log-slow-queries command-line option
and log, log_slow_queries system-variables for v7.0; they
are superseded by general_log/general_log_file and
slow_query_log/slow_query_log_file, respectively.

mysql-test/r/log_basic.result:
  Change deprecated system variable "log" to
  general log.
mysql-test/r/log_bin_trust_routine_creators_basic.result:
  Change deprecation warning so it's more obvious we're referring
  to a variable.
mysql-test/r/log_state.result:
  Show that all log-related server variables that
  should throw deprecation warnings do, and the
  others don't.
mysql-test/r/warnings.result:
  Change deprecation warning so it's more obvious we're referring
  to a variable.
mysql-test/suite/rpl/r/rpl_sp.result:
  Change deprecation warning so it's more obvious we're referring
  to a variable.
mysql-test/t/log_basic.test:
  Change deprecated system variable "log" to
  general log.
mysql-test/t/log_state.test:
  Show that all log-related server variables that
  should throw deprecation warnings do, and the
  others don't.
sql/mysqld.cc:
  Add command-line options --general-log-file and
  --slow-query-log-file to match server options of
  the same name.
  
  Deprecated --log and --log-slow-queries command-line
  options; they are superseded by --general-log/
  --general-log-file and --slow-query-log/--slow-query-log-file,
  respectively
sql/set_var.cc:
  Deprecate system-variables log in favour of general_log,
  log_slow_queries in favour of slow_query_log for 7.0,
  both for value- and DEFAULT-setting.

crashes server

When creating temporary table that contains aggregate functions a 
non-reversible source transformation was performed to redirect aggregate
function arguments towards temporary table columns.
This caused EXPLAIN EXTENDED to fail because it was trying to resolve
references to the (freed) temporary table.
Fixed by preserving the original aggregate function arguments and
using them (instead of the transformed ones) for EXPLAIN EXTENDED.

mysql-test/r/explain.result:
  Bug#34773: test case
mysql-test/t/explain.test:
  Bug#34773: test case
sql/item.cc:
  Bug#34773: use accessor functions instead of public members
sql/item_sum.cc:
  Bug#34773: 
   - Encapsulate the arguments into Item_sum and
     provide accessor and mutator methods 
   - print the orginal arguments (if present)
     in EXPLAIN EXTENDED
   - preserve the original arguments list.
sql/item_sum.h:
  Bug#34773: 
   - Encapsulate the arguments into Item_sum and
     provide accessor and mutator methods 
   - print the orginal arguments (if present)
     in EXPLAIN EXTENDED
   - preserve the original arguments list.
sql/opt_range.cc:
  Bug#34773: use accessor functions instead of public members
sql/opt_sum.cc:
  Bug#34773: use accessor functions instead of public members
sql/sql_select.cc:
  Bug#34773: use accessor functions instead of public members

"Trigger fired multiple times leads to gaps in auto_increment sequence".
The bug was that if a trigger fired multiple times inside a top
statement (for example top-statement is a multi-row INSERT,
and trigger is ON INSERT), and that trigger inserted into an auto_increment
column, then gaps could be observed in the auto_increment sequence,
even if there were no other users of the database (no concurrency).
It was wrong usage of THD::auto_inc_intervals_in_cur_stmt_for_binlog.
Note that the fix changes "class handler", I'll tell the Storage Engine API team.

mysql-test/r/trigger-trans.result:
  result; before the bugfix, the sequence was 1,2,4,6,8,10,12...
mysql-test/t/trigger-trans.test:
  test for BUG#31612
sql/handler.cc:
  See revision comment of handler.h.
  As THD::auto_inc_intervals_in_cur_stmt_for_binlog is cumulative
  over all trigger invokations by the top statement, the
  second invokation of the trigger arrived in handler::update_auto_increment()
  with already one interval in
  THD::auto_inc_intervals_in_cur_stmt_for_binlog. The method thus
  believed it had already reserved one interval for that invokation,
  thus reserved a twice larger interval (heuristic when we don't know
  how large the interval should be: we grow by powers of two). InnoDB
  thus increased its internal per-table auto_increment counter by 2
  while only one row was to be inserted. Hence a gap in the sequence.
  The fix is to use the new handler::auto_inc_intervals_count.
  Note that the trigger's statement knows how many rows it is going
  to insert, but provides estimation_rows_to_insert == 0 (see comments
  in sql_insert.cc why triggers don't call handler::ha_start_bulk_insert()).
  * removing white space at end of line
  * we don't need to maintain THD::auto_inc_intervals_in_cur_stmt_for_binlog
  if no binlogging or if row-based binlogging. Using auto_inc_intervals_count in
  the heuristic makes the heuristic independent of binary logging, which is good.
sql/handler.h:
  THD::auto_inc_intervals_in_cur_stmt_for_binlog served
   - for binlogging
   - as a heuristic when we have no estimation of how many records the
     statement will insert.
  But the first goal needs to be cumulative over all statements which
  form a binlog event, while the second one needs to be attached to each
  statement. THD::auto_inc_intervals_in_cur_stmt_for_binlog is cumulative,
  leading to BUG#31612. So we introduce handler::auto_inc_intervals_count
  for the second goal. See the revision comment of handler.cc.
  A smaller issue was that, even when the binlog event was only one
  statement (no triggers, no stored functions),
  THD::auto_inc_intervals_in_cur_stmt.nb_elements() could be lower than
  the number of reserved intervals (fooling the heuristic), because its
  append() method collapses two contiguous intervals in one.
  Note that as auto_inc_intervals_count is in class 'handler' and not
  in class 'THD', it does not need to be handled in
  THD::reset|restore_sub_statement_state().
sql/log.cc:
  Comment is wrong: if auto_increment is second, in handler::update_auto_increment()
  'append' is false and so auto_inc_intervals_in_cur_stmt_for_binlog
  is empty, we do not come here.
sql/sql_class.h:
  comment

MyISAM blocks index usage for bulk insert into zero-records tables.
See ha_myisam::start_bulk_insert() lines from
...
    if (file->state->records == 0 ...
...

That causes problems for partition engine when some partitions have records some not
as the engine uses same access method for all partitions.

Now partition engine doesn't call index_first/index_last
for empty tables.

per-file comments:
  mysql-test/r/partition.result
        Bug#38005 Partitions: error with insert select.
        test result

  mysql-test/t/partition.test
        Bug#38005 Partitions: error with insert select.
        test case

  sql/ha_partition.cc
        Bug#38005 Partitions: error with insert select.
        ha_engine::index_first and
        ha_engine::index_last not called for empty tables.