'CREATE TABLE IF NOT EXISTS ... SELECT' behaviour
BUG#55474, BUG#55499, BUG#55598, BUG#55616 and BUG#55777 are fixed
in this patch too.

This is the 5.1 part.
It implements:
- if the table exists, binlog two events: CREATE TABLE IF NOT EXISTS
  and INSERT ... SELECT

- Insert nothing and binlog nothing on master if the existing object
  is a view. It only generates a warning that table already exists.


mysql-test/r/trigger.result:
  Ather this patch, 'CREATE TABLE IF NOT EXISTS ... SELECT' will not
  insert anything if the creating table already exists and is a view.
sql/sql_class.h:
  Declare virtual function write_to_binlog() for select_insert.
  It's used to binlog 'create select'
sql/sql_insert.cc:
  Implement write_to_binlog();
  Use write_to_binlog() instead of binlog_query() to binlog the statement.
  if the table exists, binlog two events: CREATE TABLE IF NOT EXISTS
  and INSERT ... SELECT
sql/sql_lex.h:
  Declare create_select_start_with_brace and create_select_pos.
  They are helpful for binlogging 'create select'
sql/sql_parse.cc:
  Do nothing on master if the existing object is a view.
sql/sql_yacc.yy:
  Record the relative postion of 'SELECT' in the 'CREATE ...SELECT' statement.
  Record whether there is a '(' before the 'SELECT' clause.

The server was not checking for errors generated during
the execution of Item::val_xxx() methods when copying
data to the group, order, or distinct temp table's row.
Fixed by extending the copy_funcs() to return an error
code and by checking for that error code on the places
copy_funcs() is called. 
Test case added.

variable assignments

The assert() that is firing is checking if expressions that can't be
null return a NULL when evaluated.
MAKEDATE() function can return NULL if the second argument is 
less then or equal to 0. Thus its nullability depends not only on 
the nullability of its arguments but also on their values.
Fixed by (overoptimistically) setting MAKEDATE() to be nullable 
despite the nullability of its arguments.
Test added.
Had to update one test result to reflect the metadata change.

feature

The test for bug no 50939 was put in range.test which isn't such a good idea
since it requires partitioning. Fixed by moving the test case to
partitioning_range.test.

Updated the README file.

           INSERT IGNORE ... SELECT ... UNION SELECT ...

This assert was triggered by INSERT IGNORE ... SELECT. The assert checks that a
statement either sends OK or an error to the client. If the bug was triggered
on release builds, it caused OK to be sent to the client instead of the correct
error message (in this case ER_FIELD_SPECIFIED_TWICE).

The reason the assert was triggered, was that lex->no_error was set to TRUE
during JOIN::optimize() because of IGNORE. This causes all errors to be ignored.
However, not all errors can be ignored. Some, such as ER_FIELD_SPECIFIED_TWICE
will cause the INSERT to fail no matter what. But since lex->no_error was set,
the critical errors were ignored, the INSERT failed and neither OK nor the
error message was sent to the client.

This patch fixes the problem by temporarily turning off lex->no_error in
places where errors cannot be ignored during processing of INSERT ... SELECT.

Test case added to insert.test.

read_rnd_buffer_size

Applied the updated description from Paul's patch.

Undo workaround as fix is being merged in

failures on sparc64.

file .\item_subselect.cc, line 836

IN quantified predicates are never executed directly. They are rather wrapped
inside nodes called IN Optimizers (Item_in_optimizer) which take care of the
execution. However, this is not done during query preparation. Unfortunately
the LIKE predicate pre-evaluates constant right-hand side arguments even
during name resolution. Likely this is meant as an optimization.

Fixed by not pre-evaluating LIKE arguments in view prepare mode.

Reverted the ulong->uint diff
Re-applied the first diff.
The original commit message follows:

enum plugin system variables are ulong internally, not int.
On systems where long is not the same as an int it causes
problems. 
Fixed by correct typecasting. Removed the test from the 
experimental list.

Follow-up patch: added test cases for -0 and while

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.

if() treated any non-numeric string as false
Fixed to treat those as true instead
Added some test cases
Fixed missing $ in variable name in include/mix2.inc

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/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

The expect file can now include "restart:<server options>"
Also drop check-testcase if this has been done
Added comment explaining the restart: syntax

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.

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.

Fix a regression (due to a typo) which caused spurious incorrect
argument errors for long data stream parameters if all forms of
logging were disabled (binary, general and slow logs).

sql/sql_prepare.cc:
  Add a missing logical NOT operator.

Fix a regression (due to a typo) which caused spurious incorrect
argument errors for long data stream parameters if all forms of
logging were disabled (binary, general and slow logs).

mysql-test/t/mysql_client_test.test:
  Save the status of the slow_log.
sql/sql_prepare.cc:
  Add a missing logical NOT operator.
tests/mysql_client_test.c:
  Disable all query logs when running C tests. Fixes a omission
  when, slow log should have been disabled too.
  
  Run test case for Bug#54041 with query logs enabled and disabled.

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_mixed_load_data.test:
  Added the test file to verify that 'load data infile...' statement
  will go to row-based in mixed mode.
sql/sql_load.cc:
  Added code to go to row-based in mixed mode for
  'load data infile ...' statement

The problem is that the fix Bug#29784 was mistakenly
reverted when updating YaSSL to a newer version.

The solution is to re-apply the fix and this time
actually add a meaningful test case so that possible
regressions are caught.

extra/yassl/taocrypt/src/coding.cpp:
  Fixed buffer allocation to compute the proper maximum
  decoded size: (EncodedLength * 3/4) + 3
mysql-test/std_data/server8k-cert.pem:
  Update certificate.
mysql-test/std_data/server8k-key.pem:
  Update key.
mysql-test/t/ssl_8k_key-master.opt:
  Start the server using the certificate and key that
  triggers the problem.

Problem: The original patch didn't compile on debug_werror
due to wrong format in printf("%d") for size_t variables.

Fix: Adding cast to (int).

/*![:version:] Query Code */, where [:version:] is a sequence of 5 
digits representing the mysql server version(e.g /*!50200 ... */),
is a special comment that the query in it can be executed on those 
servers whose versions are larger than the version appearing in the 
comment. It leads to a security issue when slave's version is larger 
than master's. A malicious user can improve his privileges on slaves. 
Because slave SQL thread is running with SUPER privileges, so it can
execute queries that he/she does not have privileges on master.

This bug is fixed with the logic below: 
- To replace '!' with ' ' in the magic comments which are not applied on
  master. So they become common comments and will not be applied on slave.

- Example:
  'INSERT INTO t1 VALUES (1) /*!10000, (2)*/ /*!99999 ,(3)*/
  will be binlogged as
  'INSERT INTO t1 VALUES (1) /*!10000, (2)*/ /* 99999 ,(3)*/

mysql-test/suite/rpl/t/rpl_conditional_comments.test:
  Test the patch for this bug.
sql/mysql_priv.h:
  Rename inBuf as rawBuf and remove the const limitation.
sql/sql_lex.cc:
  To replace '!' with ' ' in the magic comments which are not applied on
  master.
sql/sql_lex.h:
  Remove the const limitation on parameter buff, as it can be modified in the function since
  this patch.
  Add member function yyUnput for Lex_input_stream. It set a character back the query buff.
sql/sql_parse.cc:
  Rename inBuf as rawBuf and remove the const limitation.
sql/sql_partition.cc:
  Remove the const limitation on parameter part_buff, as it can be modified in the function since
  this patch.
sql/sql_partition.h:
  Remove the const limitation on parameter part_buff, as it can be modified in the function since
  this patch.
sql/table.h:
  Remove the const limitation on variable partition_info, as it can be modified since
  this patch.

The expect file can now include "restart:<server options>"
Also drop check-testcase if this has been done

to mysql-5.1-innodb plugin.

Do not attempt to test the innodb plugin with the embedded server,
it's not supported for now.

Problem: The functions my_like_range_xxx() returned
badly formed maximum strings for Asian character sets,
which made problems for storage engines.

Fix: 
- Removed a number my_like_range_xxx() implementations,
  which were in fact dumplicate code pieces.
- Using generic my_like_range_mb() instead.
- Setting max_sort_char member properly for Asian character sets
- Adding unittest/strings/strings-t.c, 
  to test that my_like_range_xxx() return well-formed 
  min and max strings.

Notes:

- No additional tests in mysql/t/ available.
  Old tests cover the affected code well enough.

InnoDB Plugin 1.0.10 has been released with MySQL 5.1.49.