Triggers in SBR mode."
BUG#14914 "SP: Uses of session variables in routines are not always
           replicated"
BUG#25167 "Dupl. usage of user-variables in trigger/function is not
           replicated correctly"

User-defined variables used inside of stored functions/triggers in
statements which did not update tables directly were not replicated.
We also had problems with replication of user-defined variables which
were used in triggers (or stored functions called from table-updating
statements) more than once.

This patch addresses the first issue by enabling logging of all
references to user-defined variables in triggers/stored functions
and not only references from table-updating statements.

The second issue stemmed from the fact that for user-defined
variables used from triggers or stored functions called from
table-updating statements we were writing binlog events for each
reference instead of only one event for the first reference.
This problem is already solved for stored functions called from
non-updating statements with help of "event unioning" mechanism.
So the patch simply extends this mechanism to the case affected.
It also fixes small problem in this mechanism which caused wrong
logging of references to user-variables in cases when non-updating
statement called several stored functions which used the same
variable and some of these function calls were omitted from binlog
as they were not updating any tables.

into  mysql_cab_desk.:C:/source/c++/mysql-5.0_BUG_21490

This patch deprecates the replication startup options in the configuration
file and on the command line. The options deprecated include:

MASTER_HOST, MASTER_USER, MASTER_PASSWORD, MASTER_PORT, MASTER_CONNECT_RETRY,
MASTER_SSL, MASTER_SSL_CA, MASTER_SSL_CAPATH, MASTER_SSL_CERT, MASTER_SSL_KEY,
and MASTER_SSL_CIPHER

The code is designed to print the warning message once.

into  mysql.com:/nfsdisk1/lars/MERGE/mysql-5.0-merge

into  mysql.com:/nfsdisk1/lars/MERGE/mysql-5.0-merge

into  mysql.com:/nfsdisk1/lars/MERGE/mysql-4.1-merge

into  bodhi.local:/opt/local/work/mysql-5.0-runtime-debug-max

by the patch for Bug#4968

into  bodhi.local:/opt/local/work/mysql-5.0-runtime

into  mockturtle.local:/home/dlenev/src/mysql-5.0-bg20390-2

into  weblab.(none):/home/marcsql/TREE/mysql-5.0-6298

into  bodhi.local:/opt/local/work/mysql-5.0-runtime

into  bodhi.local:/opt/local/work/mysql-5.0-runtime

into  trift2.:/MySQL/M50/push-5.0

into  mockturtle.local:/home/dlenev/src/mysql-5.0-bg20390-2

into  bodhi.local:/opt/local/work/mysql-5.0-4968-to-push

into  bodhi.local:/opt/local/work/mysql-4.1-4968-to-push

of untouched rows in full table scans".

SELECT ... FOR UPDATE/LOCK IN SHARE MODE statements as well as
UPDATE/DELETE statements which were executed using full table
scan were not releasing locks on rows which didn't satisfy
WHERE condition.
This bug surfaced in 5.0 and affected NDB tables. (InnoDB tables
intentionally don't support such unlocking in default mode).

This problem occured because code implementing join didn't call
handler::unlock_row() for rows which didn't satisfy part of condition
attached to this particular table/level of nested loop. So we solve
the problem adding this call.
Note that we already had this call in place in 4.1 but it was lost
(actually not quite correctly placed) when we have introduced nested 
joins.

Also note that additional QA should be requested once this patch is
pushed as interaction between handler::unlock_row() and many recent
MySQL features such as subqueries, unions, views is not tested enough.

into  bodhi.local:/opt/local/work/mysql-5.0-runtime

into  bodhi.local:/opt/local/work/mysql-5.0-runtime

into  trift2.:/MySQL/M50/push-5.0

into  bodhi.local:/opt/local/work/mysql-4.1-runtime

into  trift2.:/MySQL/M41/mysql-4.1

into  mysql.com:/nfsdisk1/lars/MERGE/mysql-5.0-merge

into  mysql.com:/nfsdisk1/lars/MERGE/mysql-4.1-merge

into  mysql.com:/home/gluh/MySQL/Merge/5.0

into  mysql.com:/home/gluh/MySQL/Merge/5.0

into  trift2.:/MySQL/M41/push-4.1

  Patch from Paul DuBois for better help messages

into  bodhi.local:/opt/local/work/mysql-5.0-runtime

into  bodhi.local:/opt/local/work/mysql-5.0-runtime

into  bodhi.local:/opt/local/work/mysql-4.1-runtime

into  rakia.gmz:/home/kgeorge/mysql/autopush/B25106-5.0-opt

           aliases ignored
When a column reference to a column in JOIN USING is resolved and a new 
Item is created for this column the user defined name was lost.
This fix preserves the alias by setting the name of the new Item to the
original alias.