When starting the (5.1+) mysql command-line client, we try to get
"select @@version_comment" from the server to present it to the
user. Recent clients are aware that older servers do not have that
variable and fall back on other info to be able to present *something*
at least. This fallback string was allocated through the POSIX interface,
but released through the my*() suite, which rightfully complained about
the imbalance in calls when compiled with --debug. While this wasn't
as bad as it looked (no double-free, use of uninitialized or freed
buffer, etc.), it did look funky.

Using my_strdup() now for what will be my_free()d later.

client/mysql.cc:
  Use my_strdup() for server_version, as we'll my_free() it later
  and don't want to upset the mysql client's memory accounting.

BUG#41597 - After rename of user, there are additional grants
            when grants are reapplied.

Fixed build failure on Windows. Added missing cast.

sql/sql_acl.cc:
  Fixed build failure on Windows. Added missing cast.

      
If the first argument to GeomFromWKB function is a geometry
field then the function just returns its value.
However in doing so it's not preserving first argument's 
null_value flag and this causes unexpected null value to
be returned to the calling function.
      
Fixed by updating the null_value of the GeomFromWKB function
in such cases (and all other cases that return a NULL e.g.
because of not enough memory for the return buffer).

Problem: involving a spatial index for "non-spatial" queries
(that don't containt MBRXXX() functions) may lead to failed assert.

Fix: don't use spatial indexes in such cases.


mysql-test/r/gis-rtree.result:
  Fix for bug#48258: Assertion failed when using a spatial index
    - test result.
mysql-test/t/gis-rtree.test:
  Fix for bug#48258: Assertion failed when using a spatial index
    - test case.
sql/opt_range.cc:
  Fix for bug#48258: Assertion failed when using a spatial index
    - allow only spatial functions (MBRXXX) for itMBR keyparts.

line 138 when forcing a spatial index

Problem: "Spatial indexes can be involved in the search 
for queries that use a function such as MBRContains() 
or MBRWithin() in the WHERE clause".
Using spatial indexes for JOINs with =, <=> etc.
predicates is incorrect.

Fix: disable spatial indexes for such queries.


mysql-test/r/select.result:
  Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, 
  line 138 when forcing a spatial index
    - test result.
mysql-test/t/select.test:
  Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, 
  line 138 when forcing a spatial index
    - test case.
sql/sql_select.cc:
  Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, 
  line 138 when forcing a spatial index
    - disable spatial indexes for queries which use 
  non-spatial conditions (e.g. NATURAL JOINs).

                     grants are reapplied.


After renaming a user and trying to re-apply grants results in additional
grants.

This is because we use username as part of the key for GRANT_TABLE structure.
When the user is renamed, we only change the username stored and the hash key
still contains the old user name and this results in the extra privileges

Fixed by rebuilding the hash key and updating the column_priv_hash structure
when the user is renamed

mysql-test/r/grant3.result:
  Bug #41597 - After rename of user, there are additional grants when 
               grants are reapplied.
  
  Testcase for BUG#41597
mysql-test/t/grant3.test:
  Bug #41597 - After rename of user, there are additional grants when 
               grants are reapplied.
  
  Testcase for BUG#41597
sql/sql_acl.cc:
  Bug #41597 - After rename of user, there are additional grants when 
               grants are reapplied.
  
  Fixed handle_grant_struct() to update the hash key when the user is renamed.
  Added to set_user_details() method to GRANT_NAME class

If a thread is killed in the server, we throw "shutdown" only if one is actually in
progress; otherwise, we throw "query interrupted".

Control-C in the mysql command-line client is "incremental" now.
First Control-C sends KILL QUERY (when connected to 5.0+ server, otherwise, see next)
Next  Control-C sends KILL CONNECTION
Next  Control-C aborts client.

As the first two steps only pertain to an existing query,
Control-C will abort the client right away if no query is running.

client will give more detailed/consistent feedback on Control-C now.


client/mysql.cc:
  Extends Control-C handling; enhances up feedback to user.
  
  On 5.0+ servers, we try to be nice and send KILL QUERY first
  if Control-C is pressed in the command-line client, but if
  that doesn't work, we now give the user the opportunity to
  send KILL CONNECTION with another Control-C (and to kill the
  client with another Control-C if that somehow doesn't work
  either).
mysql-test/t/flush_read_lock_kill.test:
  we're getting correct "thread killed" rather than
  "in shutdown" error now
mysql-test/t/kill.test:
  we're getting correct "thread killed" rather than
  "in shutdown" error now
mysql-test/t/rpl000001.test:
  we're getting correct "thread killed" rather than
  "in shutdown" error now
mysql-test/t/rpl_error_ignored_table.test:
  we're getting correct "thread killed" rather than
  "in shutdown" error now
sql/records.cc:
  make error messages on KILL uniform for rr_*()
  by folding that handling into rr_handle_error()
sql/sql_class.h:
  Only throw "shutdown" when we have one flagged as being in progress;
  otherwise, throw "query interrupted" as it's likely to be "KILL CONNECTION"
  or related.

  UPDATE + VIEW + SP + MERGE + ALTER

When cleaning up the stored procedure's internal 
structures the flag to ignore the errors for 
INSERT/UPDATE IGNORE was not cleaned up.
As a result error ignoring was on during name 
resolution. And this is an abnormal situation : the
SELECT_LEX flag can be on only during query execution.

Fixed by correctly cleaning up the SELECT_LEX flag 
when reusing the SELECT_LEX in a second execution.

SP variables

A function call may end without throwing an error or without setting 
the return value. This can happen when e.g. an error occurs while 
calculating the return value.

Fixed by setting the value to NULL when error occurs during evaluation
of an expression.

fail.

This assertion would occur if UPDATE was used to update multiple
tables containing an AUTO_INCREMENT column and if the inserted
row had a user-supplied value for that column. The assertion 
could then be triggered by the next statement.

The problem was only noticeable on debug builds of the server.

The cause of the problem was that the code for multi update did
not properly reset the TABLE->auto_increment_if_null flag after update.
The flag is used to indicate that a non-null value of an auto_increment field
has been provided by the user or retrieved from a current record.
Open_tables() contains an assertion that tests this flag, and this
was triggered in this case by ALTER TABLE.

This patch fixes the problem by resetting the auto_increment_if_null
field to FALSE once a row has been updated.

This bug is similar to Bug#47274, but for multi update rather
than INSERT DELAYED.

Test case added to update.test.

Added parentheses around assignment used as truth value for suppressing warnings.

(automerge)

The label "end" was causing compiler warnings as it was no longer used.
To fix the problem we removed it.

file
      
Issuing 'FLUSH LOGS' does not close and reopen indexfile.
Instead a SEEK_SET is performed.
      
This patch makes index file to be closed and reopened whenever a
rotation happens (FLUSH LOGS is issued or binary log exceeds 
maximum configured size).

mysql-test/suite/binlog/r/binlog_delete_and_flush_index.result:
  Result file.
mysql-test/suite/binlog/t/binlog_delete_and_flush_index.test:
  Test case.
sql/log.cc:
  Added LOG_CLOSE_INDEX flag when calling MYSQL_BIN_LOG::close
  from within MYSQL_BIN_LOG::new_file_impl (which should just be
  called whenever a rotation is to happen - FLUSH LOGS issued or
  binlog size exceeds the maximum configured).

- Initialized caseinfo only if it is NULL

There are some problems about help text:
- It is stated that "auto" is the default twice. It need be stated only once.
- It is stated that --base64-output is short for --base64-output=always. But that sounds
like the default is "always", not "auto".

Make the help text clear as following:
Determine when the output statements should be base64-encoded BINLOG 
statements: 'never' disables it and works only for binlogs without 
row-based events; 'auto' prints base64 only when necessary (i.e., 
for row-based events and format description events); 'always' prints 
base64 whenever possible. 'always' is for debugging only and should 
not be used in a production system. If this argument is not given, 
the default is 'auto'; if it is given with no argument, 'always' is used.

Knowledge of no SSL support is not used
Skip tests the same way e.g. innodb tests are
Does not refer to have_ssl_communication.inc, 
     will add this when merging to 6.0-codebase

Problem: the "caseinfo" member of CHARSET_INFO structure was not
initialized for user-defined Unicode collations, which made the
server crash.
Fix: initializing caseinfo properly.