The enum system variables were handled inconsistently 
as ints, unsigned int and unsigned long on various places.
This caused problems on platforms on which 
sizeof(int) != sizeof(long).
Fixed by homogenizing the type of the enum variables
to unsigned int, since it's size compatible with the C enum
type. 
Removed the test from the experimental list.

The problem reported in BUG#55625 does not happen in mysql-trunk
when the logging format is row. However, a "CREATE SELECT" that
fails when the logging format is statement is not written to
the binary log. 

This problem will be addressed in BUG#47899.

Post fix

mysql-test/t/mysqlbinlog.test:
  Updated for Bug#34283

Post fix

mysql-test/t/mysqlbinlog.test:
  Updated for Bug#34283

      
With statement- or mixed-mode logging, "LOAD DATA INFILE" queries
are written to the binlog using special types of log events.
When mysqlbinlog reads such events, it re-creates the file in a
temporary directory with a generated filename and outputs a
"LOAD DATA INFILE" query where the filename is replaced by the
generated file. The temporary file is not deleted by mysqlbinlog
after termination.
      
To fix the problem, in mixed mode we go to row-based. In SBR, we
document it to remind user the tmpfile is left in a temporary
directory.


mysql-test/suite/binlog/r/binlog_mixed_load_data.result:
  Test result for BUG#34283.
mysql-test/suite/binlog/t/binlog_killed_simulate.test:
  Updated for BUg#34283
mysql-test/suite/binlog/t/binlog_mixed_load_data.test:
  Added the test file to verify that 'load data infile...' statement
  will go to row-based in mixed mode.
mysql-test/suite/binlog/t/binlog_stm_blackhole.test:
  Updated for BUg#34283
mysql-test/suite/rpl/r/rpl_innodb_mixed_dml.result:
  Updated for Bug#34283
mysql-test/suite/rpl/t/rpl_loaddata.test:
  Updated for Bug#34283
mysql-test/suite/rpl/t/rpl_loaddata_fatal.test:
  Updated for Bug#34283
mysql-test/suite/rpl/t/rpl_loaddata_map.test:
  Updated for Bug#34283
mysql-test/suite/rpl/t/rpl_slave_load_remove_tmpfile.test:
  Updated for Bug#34283
mysql-test/suite/rpl/t/rpl_stm_log.test:
  Updated for B
mysys/stacktrace.c:
  Auto merge
sql/sql_lex.cc:
  Auto merg
sql/sql_load.cc:
  Added code to go to row-based in mixed mode for
  'load data infile ...' statement

With statement- or mixed-mode logging, "LOAD DATA INFILE" queries
are written to the binlog using special types of log events.
When mysqlbinlog reads such events, it re-creates the file in a
temporary directory with a generated filename and outputs a
"LOAD DATA INFILE" query where the filename is replaced by the
generated file. The temporary file is not deleted by mysqlbinlog
after termination.

To fix the problem, in mixed mode we go to row-based. In SBR, we
document it to remind user the tmpfile is left in a temporary
directory.




mysql-test/extra/rpl_tests/rpl_loaddata.test:
  Updated for Bug#34283
mysql-test/suite/binlog/r/binlog_mixed_load_data.result:
  Test result for BUG#34283.
mysql-test/suite/binlog/t/binlog_killed_simulate.test:
  Updated for Bug#34283
mysql-test/suite/binlog/t/binlog_mixed_load_data.test:
  Added the test file to verify that 'load data infile...' statement
  will go to row-based in mixed mode.
mysql-test/suite/binlog/t/binlog_stm_blackhole.test:
  Updated for Bug#34283
mysql-test/suite/rpl/r/rpl_innodb_mixed_dml.result:
  Updated for Bug#34283
mysql-test/suite/rpl/t/rpl_loaddata_fatal.test:
  Updated for Bug#34283
mysql-test/suite/rpl/t/rpl_loaddata_map.test:
  Updated for Bug#34283
mysql-test/suite/rpl/t/rpl_slave_load_remove_tmpfile.test:
  Updated for Bug#34283
mysql-test/suite/rpl/t/rpl_stm_log.test:
  Updated for Bug#34283
sql/sql_load.cc:
  Added code to go to row-based in mixed mode for
  'load data infile ...' statement

A CREATE...SELECT that fails is written to the binary log if a non-transactional
statement is updated. If the logging format is ROW, the CREATE statement and the
changes are written to the binary log as distinct events and by consequence the
created table is not rolled back in the slave.

In this patch, we opted to let the slave goes out of sync by not writting to the
binary log the CREATE statement. We do this by simply reseting the binary log's
cache.

mysql-test/suite/rpl/r/rpl_drop.result:
  Added a test case.
mysql-test/suite/rpl/t/rpl_drop.test:
  Added a test case.
sql/log.cc:
  Introduced a function to clean up the cache.
sql/log.h:
  Introduced a function to clean up the cache.
sql/sql_insert.cc:
  Cleaned up the binary log cache if a CREATE...SELECT fails.

Queries may crash, if
  1) the GREATEST or the LEAST function has a mixed list of
     numeric and LONGBLOB arguments and
  2) the result of such a function goes through an intermediate
     temporary table.

An Item that references a LONGBLOB field has max_length of
UINT_MAX32 == (2^32 - 1).

The current implementation of GREATEST/LEAST returns REAL
result for a mixed list of numeric and string arguments (that
contradicts with the current documentation, this contradiction
was discussed and it was decided to update the documentation).

The max_length of such a function call was calculated as a
maximum of argument max_length values (i.e. UINT_MAX32).

That max_length value of UINT_MAX32 was used as a length for
the intermediate temporary table Field_double to hold
GREATEST/LEAST function result.

The Field_double::val_str() method call on that field
allocates a String value.

Since an allocation of String reserves an additional byte
for a zero-termination, the size of String buffer was
set to (UINT_MAX32 + 1), that caused an integer overflow:
actually, an empty buffer of size 0 was allocated.

An initialization of the "first" byte of that zero-size
buffer with '\0' caused a crash.

The Item_func_min_max::fix_length_and_dec() has been
modified to calculate max_length for the REAL result like
we do it for arithmetical operators.


******
Bug #54461: crash with longblob and union or update with subquery

Queries may crash, if
  1) the GREATEST or the LEAST function has a mixed list of
     numeric and LONGBLOB arguments and
  2) the result of such a function goes through an intermediate
     temporary table.

An Item that references a LONGBLOB field has max_length of
UINT_MAX32 == (2^32 - 1).

The current implementation of GREATEST/LEAST returns REAL
result for a mixed list of numeric and string arguments (that
contradicts with the current documentation, this contradiction
was discussed and it was decided to update the documentation).

The max_length of such a function call was calculated as a
maximum of argument max_length values (i.e. UINT_MAX32).

That max_length value of UINT_MAX32 was used as a length for
the intermediate temporary table Field_double to hold
GREATEST/LEAST function result.

The Field_double::val_str() method call on that field
allocates a String value.

Since an allocation of String reserves an additional byte
for a zero-termination, the size of String buffer was
set to (UINT_MAX32 + 1), that caused an integer overflow:
actually, an empty buffer of size 0 was allocated.

An initialization of the "first" byte of that zero-size
buffer with '\0' caused a crash.

The Item_func_min_max::fix_length_and_dec() has been
modified to calculate max_length for the REAL result like
we do it for arithmetical operators.



mysql-test/r/func_misc.result:
  Test case for bug #54461.
  
  ******
  Test case for bug #54461.
mysql-test/t/func_misc.test:
  Test case for bug #54461.
  
  ******
  Test case for bug #54461.
sql/item_func.cc:
  Bug #54461: crash with longblob and union or update with subquery
  
  The Item_func_min_max::fix_length_and_dec() has been
  modified to calculate max_length for the REAL result like
  we do it for arithmetical operators.
  
  ******
  Bug #54461: crash with longblob and union or update with subquery
  
  The Item_func_min_max::fix_length_and_dec() has been
  modified to calculate max_length for the REAL result like
  we do it for arithmetical operators.

scripts if cmake is available. We need to always generate the
scripts in order for the dual cmake/autotools support to work.

Fix compiler warnings.

mysys/stacktrace.c:
  Tag unused parameters.
sql/sql_lex.cc:
  Variable becomes unused in non-debug builds. Also, no need to
  assert the obvious.

******
This patch fixes the following bugs:
  - Bug#5889: Exit handler for a warning doesn't hide the warning in
    trigger
  - Bug#9857: Stored procedures: handler for sqlwarning ignored
  - Bug#23032: Handlers declared in a SP do not handle warnings generated
    in sub-SP
  - Bug#36185: Incorrect precedence for warning and exception handlers

The problem was in the way warnings/errors during stored routine execution
were handled. Prior to this patch the logic was as follows:

  - when a warning/an error happens: if we're executing a stored routine,
    and there is a handler for that warning/error, remember the handler,
    ignore the warning/error and continue execution.

  - after a stored routine instruction is executed: check for a remembered
    handler and activate one (if any).

This logic caused several problems:

  - if one instruction generates several warnings (errors) it's impossible
    to choose the right handler -- a handler for the first generated
    condition was chosen and remembered for activation.

  - mess with handling conditions in scopes different from the current one.

  - not putting generated warnings/errors into Warning Info (Diagnostic
    Area) is against The Standard.

The patch changes the logic as follows:

  - Diagnostic Area is cleared on the beginning of each statement that
    either is able to generate warnings, or is able to work with tables.

  - at the end of a stored routine instruction, Diagnostic Area is left
    intact.

  - Diagnostic Area is checked after each stored routine instruction. If
    an instruction generates several condition, it's now possible to take a
    look at all of them and determine an appropriate handler.

mysql-test/r/signal.result:
  Update result file:
    1. handled conditions are not cleared any more;
    2. reflect changes in signal.test
mysql-test/r/signal_demo3.result:
  Update result file: handled conditions are not cleared any more.
  Due to playing with max_error_count, resulting warning lists
  have changed.
mysql-test/r/sp-big.result:
  Update result file: handled conditions are not cleared any more.
mysql-test/r/sp-bugs.result:
  Update result file: handled conditions are not cleared any more.
mysql-test/r/sp-code.result:
  Update result file:
    1. handled conditions are not cleared any more.
    2. add result for a new test case in sp-code.test.
mysql-test/r/sp-error.result:
  Update result file:
    1. handled conditions are not cleared any more.
    2. add result for a new test case in sp-error.test.
mysql-test/r/sp.result:
  Update result file: handled conditions are not cleared any more.
mysql-test/r/sp_trans.result:
  Update result file: handled conditions are not cleared any more.
mysql-test/r/strict.result:
  Update result file: handled conditions are not cleared any more.
mysql-test/r/view.result:
  Update result file: handled conditions are not cleared any more.
mysql-test/suite/funcs_1/r/innodb_storedproc_02.result:
  Update result file: handled conditions are not cleared any more.
mysql-test/suite/funcs_1/r/memory_storedproc_02.result:
  Update result file: handled conditions are not cleared any more.
mysql-test/suite/funcs_1/r/myisam_storedproc_02.result:
  Update result file: handled conditions are not cleared any more.
mysql-test/suite/funcs_1/r/storedproc.result:
  Update result file: handled conditions are not cleared any more.
mysql-test/suite/rpl/r/rpl_row_sp005.result:
  Update result file: handled conditions are not cleared any more.
mysql-test/suite/rpl/r/rpl_row_sp006_InnoDB.result:
  Update result file: handled conditions are not cleared any more.
mysql-test/suite/rpl/r/rpl_row_trig003.result:
  Update result file: handled conditions are not cleared any more.
mysql-test/t/signal.test:
  Make a test case more readable in the result file.
mysql-test/t/sp-code.test:
  Add a test case for Bug#23032 checking that
  No Data takes precedence on Warning.
mysql-test/t/sp-error.test:
  Adding test cases for:
    - Bug#23032
    - Bug#36185
    - Bug#5889
    - Bug#9857
mysql-test/t/sp.test:
  Fixing test case to reflect behavioral changes made by the patch.
sql/sp_head.cc:
  Reset the per-statement warning count before executing
  a stored procedure instruction.
  
  Move to a separate function code which checks the
  completion status of the executed statement and searches
  for a handler.
  
  Remove redundant code now that search for a handler is
  done after execution, errors are always pushed.
sql/sp_pcontext.h:
  Remove unused code.
sql/sp_rcontext.cc:
  - Polish sp_rcontext::find_handler(): use sp_rcontext::m_hfound instead
    of an extra local variable;
  
  - Remove sp_rcontext::handle_condition();
  
  - Introduce sp_rcontext::activate_handler(), which prepares
    previously found handler for execution.
  
  - Move sp_rcontext::enter_handler() code into activate_handler(),
    because enter_handler() is used only from there;
  
  - Cleanups;
  
  - Introduce DBUG_EXECUTE_IF() for a test case in sp-code.test
sql/sp_rcontext.h:
  - Remove unused code
  - Cleanups
sql/sql_class.cc:
  Merge THD::raise_condition_no_handler() into THD::raise_condition().
  After the patch raise_condition_no_handler() was called
  in raise_condition() only.
sql/sql_class.h:
  Remove raise_condition_no_handler().
sql/sql_error.cc:
  Remove Warning_info::reserve_space() -- handled conditions are not
  cleared any more, so there is no need for RESIGNAL to re-push them.
sql/sql_error.h:
  Remove Warning_info::reserve_space().
sql/sql_signal.cc:
  Handled conditions are not cleared any more,
  so there is no need for RESIGNAL to re-push them.

Revert BUG#34283.

Conflicts
=========
  Text conflict in sql/sql_load.cc
  1 conflicts encountered.

mostly because existing test result files were not updated.

In order to be able to check if the set of the grouping fields in a 
GROUP BY has changed (and thus to start a new group) the optimizer
caches the current values of these fields in a set of Cached_item 
derived objects.
The Cached_item_str, used for caching varchar and TEXT columns,
is limited in length by the max_sort_length variable.
A String buffer to store the value with an alloced length of either
the max length of the string or the value of max_sort_length 
(whichever is smaller) in Cached_item_str's constructor.
Then, at compare time the value of the string to compare to was 
truncated to the alloced length of the string buffer inside 
Cached_item_str.
This is all fine and valid, but only if you're not assigning 
values near or equal to the alloced length of this buffer.
Because when assigning values like this the alloced length is 
rounded up and as a result the next set of data will not match the
group buffer, thus leading to wrong results because of the changed
alloced_length.
Fixed by preserving the original maximum length in the 
Cached_item_str's constructor and using this instead of the 
alloced_length to limit the string to compare to.
Test case added.