fixed message for 'help' command

routine does not exist 
      
There is an inconsistency with DROP DATABASE IF EXISTS, DROP TABLE IF
EXISTS and DROP VIEW IF EXISTS: those are binlogged even if the DB or
TABLE does not exist, whereas DROP PROCEDURE IF EXISTS does not. It
would be nice or at least consistent if DROP PROCEDURE/STATEMENT
worked the same too.
      
Fixed DROP PROCEDURE|FUNCTION IF EXISTS by adding a call to
mysql_bin_log.write in mysql_execute_command. Checked also if all 
documented "DROP (...) IF EXISTS" get binlogged.
      
NOTE: This is a 5.0 backport patch as requested by support.

The crash happens due to wrong 'digits' variable value(0),
'digits' can not be 0, so the fix is use 1 as min allowed value.

While printing the Max keyfile length 'llstr' call was used which 
was treating the max_key_file_length as negative.

Changing this to ullstr fixes the problem. 
myisamchk output will differ in 32 bit and 64 bit Operating systems 
so its not possible to have test case for this bug.

      
The test started failing following the push for BUG#41541.
Some of the algorithms access bytes beyond the input data
and this can affect up to one byte less than "word size"
which is BITS_SAVED / 8. 
      
Fixed by adding (BITS_SAVED / 8) -1 bytes to buffer size
(i.e. Memory Segment #2) to avoid accessing un-allocated data.

The problem is that a SELECT .. FOR UPDATE statement might open
a table and later wait for a impeding global read lock without
noticing whether it is holding a table that is being waited upon
the the flush phase of the process that took the global read
lock.

The same problem also affected the following statements:

LOCK TABLES .. WRITE
UPDATE .. SET (update and multi-table update)
TRUNCATE TABLE ..
LOAD DATA ..

The solution is to make the above statements wait for a impending
global read lock before opening the tables. If there is no
impending global read lock, the statement raises a temporary
protection against global read locks and progresses smoothly
towards completion.

Important notice: the patch does not try to address all possible
cases, only those which are common and can be fixed unintrusively
enough for 5.0.

Bug#32136: mysqld_multi --defaults-file not respected while using \
	--mysqld=mysqld_safe

Revert change that adds "--no-defaults" to mysqld_multi.

This closes Bug#43508 and re-opens Bug#32136.

- Link against setargv.obj for wild-card expansion.

Original commentary:

Bug #37348: Crash in or immediately after JOIN::make_sum_func_list
            
The optimizer pulls up aggregate functions which should be aggregated in
an outer select. At some point it may substitute such a function for a field
in the temporary table. The setup_copy_fields function doesn't take this
into account and may overrun the copy_field buffer.
            
Fixed by filtering out the fields referenced through the specialized
reference for aggregates (Item_aggregate_ref).
Added an assertion to make sure bugs that cause similar discrepancy 
don't go undetected.

- Link against setargv.obj for wild-card expansion.

more for completeness than for relevance.

Also, update copyright notices.

updates

Attempt to execute trigger or stored function with multi-UPDATE
which used - but didn't update - a table that was also used by
the calling statement led to an error. Read-only reference to
tables used in the calling statement should be allowed.
 
This problem was caused by the fact that check for conflicting
use of tables in SP/triggers was performed in open_tables(),
and in case of multi-UPDATE we didn't know exact lock type at
this stage.

We solve the problem by moving this check to lock_tables(), so
it can be performed after exact lock types for tables used by
multi-UPDATE are determined.

  
UNION could convert fixed-point FLOAT(M,D)/DOUBLE(M,D) columns  
to FLOAT/DOUBLE when aggregating data types from the SELECT  
substatements. While there is nothing particularly wrong with  
this behavior, especially when M is greater than the hardware  
precision limits, it could be confusing in cases when all  
SELECT statements in a union have the same  
FLOAT(M,D)/DOUBLE(M,D) columns with equal precision  
specifications listed in the same position.  
  
Since the manual is quite vague on what data type should be  
returned in such cases, the bug was fixed by implementing the  
most 'expected' behavior: do not convert FLOAT(M,D)/DOUBLE(M,D)  
to anything else if all SELECT statements in a UNION have the  
same precision for that column.  

Problem: commit doesn't delete savepoints if there are no changes 
in the transaction.

Fix: delete them in such cases.

When the thread executing a DDL was killed after finished its
execution but before writing the binlog event, the error code in
the binlog event could be set wrongly to ER_SERVER_SHUTDOWN or
ER_QUERY_INTERRUPTED.

This patch fixed the problem by ignoring the kill status when
constructing the event for DDL statements.

This patch also included the following changes in order to
provide the test case.

 1) modified mysqltest to support variable for connection command

 2) modified mysql-test-run.pl, add new variable MYSQL_SLAVE to
    run mysql client against the slave mysqld.

The problem is that the read and write methods of the shared
memory transport (protocol) didn't react to asynchronous close
events, which could lead to a lock up as the client would wait
(until time out) for a server response that will never come.

The solution is to also wait for close events while waiting
for I/O from or to the server.

including modifications according to code review
+ backport of the fix for
  Bug 41932 funcs_1: is_collation_character_set_applicability path
                     too long for tar
  which was missing in 5.0 (just a renaming of two files)

      
When add an aliase name after NAME_CONST, the aliase name will be overwrite.
      
NAME_CONST will re-set the field's name only if there isn't an aliase in the
function fix-fields().
If there is an aliase, NAME_CONST doesn't re-set the field's name and keeps the old
name.

due to name_const substitution

Problem:
"In general, statements executed within a stored procedure
are written to the binary log using the same rules that
would apply were the statements to be executed in standalone
fashion. Some special care is taken when logging procedure
statements because statement execution within procedures
is not quite the same as in non-procedure context".

For example, each reference to a local variable in SP's
statements is replaced by NAME_CONST(var_name, var_value).
Queries like
"CREATE TABLE ... SELECT FUNC(local_var ..."
are logged as
"CREATE TABLE ... SELECT FUNC(NAME_CONST("local_var", var_value) ..."
that leads to differrent field names and
might result in "Incorrect column name" if var_value is long enough.

Fix: in 5.x we'll issue a warning in such a case.
In 6.0 we should get rid of NAME_CONST().

Note: this issue and change should be described in the documentation
("Binary Logging of Stored Programs").