tables open

When executing a DROP DATABASE statement in ROW mode and having temporary
tables open at the same time, the existance of temporary tables prevent
the server from switching back to row mode after temporarily switching to
statement mode to handle the logging of the statement.

Fixed the problem by removing the code to switch to statement mode and added
code to temporarily disable the binary log while dropping the objects in the
database.


mysql-test/extra/binlog_tests/database.test:
  Added test to ensure that DROP DATABASE does not affect the replication mode.
sql/sql_db.cc:
  Removed code that clears the current_stmt_binlog_row_based flag.
  Added code to disable the binary log while dropping the objects
  in a database.

      
the reason for the failure is that io thread passes through a sequence of state
changes before it eventually got stuck at the expect running state as NO.
It's unreasonble to wait for the running status while the whole idea of the test is
to get to the IO thread error.

Fixed with changing the waiting condition.

mysql-test/suite/rpl/r/rpl_server_id1.result:
  results changed
mysql-test/suite/rpl/t/disabled.def:
  re-enabling rpl_server_id1
mysql-test/suite/rpl/t/rpl_server_id1.test:
  deploying the exact waiting condition i.e to wait for the slave io error.

- Revert the fix for bug 33812
- fixed a win32 warning

client/mysql.cc:
  revert the fix for bug 33812
mysql-test/r/mysql.result:
  revert the fix for bug 33812
mysql-test/t/mysql_delimiter.sql:
  revert the fix for bug 33812
mysys/default.c:
  fixed a win32 warning

Problem: missing initialization, if the previous test
fails leaving table t1, client_xml fails as well.
Fix: adding initialization.

Many dump threads can exist due to a way the new version of mtr governs suites.

For this immediate problem the test is refined not to use I_S but rather to reconnect
explicitly with preserving logics of a an old target bug fixes verification.

mysql-test/suite/rpl/r/rpl_temporary.result:
  results changed
mysql-test/suite/rpl/t/rpl_temporary.test:
  refining the bug#17284 test to avoid counting dump threads in favor to reconnect
  explicitly with preserving the orig logics.

Don't initalize federated if it's disabled by a command line option.

sql/ha_federated.cc:
  Folow-up on Bug#37069: Don't initalize federated if it's disabled 
  by a command line option.

Reverting the previous patch

            
Range scan in descending order for c <= <col> <= c type of
ranges was ignoring the DESC flag.
However some engines like InnoDB have the primary key parts 
as a suffix for every secondary key.
When such primary key suffix is used for ordering ignoring 
the DESC is not valid.
But we generally would like to do this because it's faster.
      
Fixed by performing only reverse scan if the primary key is used.
Removed some dead code in the process.

mysql-test/r/innodb_mysql.result:
  Bug#37830 : test case
mysql-test/t/innodb_mysql.test:
  Bug#37830 : test case
sql/opt_range.cc:
  Bug#37830 : 
   - preserve and use used_key_parts to
     distinguish when a primary key suffix is used
   - removed some dead code
sql/opt_range.h:
  Bug#37830 : 
    - preserve used_key_parts
    - dead code removed
sql/sql_select.cc:
  Bug#37830 : Do only reverse order traversal
      if the primary key suffix is used.

- In QUICK_INDEX_MERGE_SELECT::read_keys_and_merge: when we got table->sort from Unique,
  tell init_read_record() not to use rr_from_cache() because a) rowids are already sorted
  and b) it might be that the the data is used by filesort(), which will need record rowids
  (which rr_from_cache() cannot provide).
- Fully de-initialize the table->sort read in QUICK_INDEX_MERGE_SELECT::get_next(). This fixes BUG#35477.
(bk trigger: file as fix for BUG#35478).

sql/filesort.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - make find_all_keys() use quick->get_next() instead of init_read_record(r)/r.read_record() calls
  - added dbug printout
sql/mysql_priv.h:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - Added parameter to init_read_record
sql/opt_range.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - In QUICK_INDEX_MERGE_SELECT::read_keys_and_merge: when we got table->sort from Unique,
    tell init_read_record() not to use rr_from_cache() because a) rowids are already sorted
    and b) it might be that the the data is used by filesort(), which will need record rowids
    (which rr_from_cache() cannot provide).
  - Fully de-initialize the table->sort read in QUICK_INDEX_MERGE_SELECT::get_next().
sql/records.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - Added disable_rr_cache parameter to init_read_record
  - Added comment
sql/sql_acl.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - Added parameter to init_read_record
sql/sql_delete.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - Added parameter to init_read_record
sql/sql_help.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - Added parameter to init_read_record
sql/sql_select.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - Added parameter to init_read_record
sql/sql_table.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - Added parameter to init_read_record
sql/sql_udf.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - Added parameter to init_read_record
sql/sql_update.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - Added parameter to init_read_record

Note: item->null_value is not updated before a call to
item->store(), item->is_null() is not too (in common case).

build)

The crash was caused by freeing the internal parser stack during the parser
execution.
This occured only for complex stored procedures, after reallocating the parser
stack using my_yyoverflow(), with the following C call stack:
- MYSQLparse()
- any rule calling sp_head::restore_lex()
- lex_end()
- x_free(lex->yacc_yyss), xfree(lex->yacc_yyvs)

The root cause is the implementation of stored procedures, which breaks the
assumption from 4.1 that there is only one LEX structure per parser call.

The solution is to separate the LEX structure into:
- attributes that represent a statement (the current LEX structure),
- attributes that relate to the syntax parser itself (Yacc_state),
so that parsing multiple statements in stored programs can create multiple
LEX structures while not changing the unique Yacc_state.

Now, Yacc_state and the existing Lex_input_stream are aggregated into
Parser_state, a structure that represent the complete state of the (Lexical +
Syntax) parser.


mysql-test/r/parser_stack.result:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
mysql-test/t/parser_stack.test:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sp.cc:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sp_head.cc:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sql_class.cc:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sql_class.h:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sql_lex.cc:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sql_lex.h:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sql_parse.cc:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sql_prepare.cc:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sql_trigger.cc:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sql_view.cc:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sql_yacc.yy:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)

            and value-list

The server returns unexpected results if a right side of the 
NOT IN clause consists of NULL value and some constants of
the same type, for example:

  SELECT * FROM t WHERE NOT t.id IN (NULL, 1, 2) 
  
may return 3, 4, 5 etc if a table contains these values.


The Item_func_in::val_int method has been modified:
unnecessary resets of an Item_func_case::has_null field 
value has been moved outside of an argument comparison
loop. (Also unnecessary re-initialization of the null_value
field has been moved).


mysql-test/r/func_in.result:
  Added test case for bug #37761.
mysql-test/t/func_in.test:
  Added test case for bug #37761.
sql/item_cmpfunc.cc:
  Bug #37761: IN handles NULL differently for table-subquery 
              and value-list
  
  The Item_func_in::val_int method has been modified:
  unnecessary resets of an Item_func_case::has_null field 
  value has been moved outside of an argument comparison
  loop. (Also unnecessary re-initialization of the null_value
  field has been moved).

libmysqld/emb_qcache.cc:
  Fixed build warning on Windows:
  ported the fix from 6.0 in 5.1