Fix for failure on windows PB2 because of the result content mismatch.
In windows additional information about TCP port was causing failures.
Added to regex.

      
The 'slave_patternload_file' is assigned to the real path of the load data file 
when initializing the object of Relay_log_info. But the path of the load data
file is not formatted to real path when executing event from relay log. So the 
error will be encountered if the path of the load data file is a symbolic link.

Actually the global 'opt_secure_file_priv' is not formatted to real path when 
loading data from file. So the same thing will happen too.

      
To fix these errors, the path of the load data file should be formatted to 
real path when executing event from relay log. And the 'opt_secure_file_priv' 
should be formatted to real path when loading data infile.


mysql-test/suite/rpl/r/rpl_loaddata_symlink.result:
  Test result for bug#43913.
mysql-test/suite/rpl/t/rpl_loaddata_symlink-master.sh:
  Added the test file to create a link from $MYSQLTEST_VARDIR/std_data 
  to $MYSQLTEST_VARDIR/std_data_master_link
mysql-test/suite/rpl/t/rpl_loaddata_symlink-slave.sh:
  Added the test file to create a link from $MYSQLTEST_VARDIR/std_data 
  to $MYSQLTEST_VARDIR/std_data_slave_link
mysql-test/suite/rpl/t/rpl_loaddata_symlink.test:
  Added the test file to verify if loading data infile will work fine 
  if the path of the load data file is a symbolic link.
sql/rpl_rli.cc:
  Added call 'my_realpath' function for avoiding sometimes the 'fn_format' 
  function can't format real path rightly.

dependent on the case mode

- embedded server doesn't support external clients
- removed unnecessary command line options

<tmp_tbl> with RBL

When binlogging the statement, the server always handle the existing
object as a table, even though it is a view. However a view is
handled differently in other parts of the code thus leading the
statement to crash in RBL if the view exists.

This happens because the underlying tables for the view are not opened
when we try to call store_create_info() on the view in order to build
a CREATE TABLE statement.

This patch will only address the crash problem, other binlogging
problems related to CREATE TABLE IF NOT EXISTS LIKE when the existing
object is a view will be solved by BUG 47442.

  is mixed case

Transcode the procedure name to lowercase when searching for it in the 
hash. This is the missing part of the fix for bug #41049.

block, might expand to function calls (Bug#48331)

for each record'

There was an error in an internal structure in the range
optimizer (SEL_ARG). Bad design causes parts of a data
structure not to be initialized when it is in a certain
state. All client code must check that this state is not
present before trying to access the structure's data. Fixed
by

- Checking the state before trying to access data (in
several places, most of which not covered by test case.)

- Copying the keypart id when cloning SEL_ARGs


mysql-test/r/range.result:
  Bug#48459: Test result.
mysql-test/t/range.test:
  Bug#48459: Test case.
sql/opt_range.cc:
  Bug#48459: Fix + doxygenated count_key_part_usage comment.

BUG#46000 - using index called GEN_CLUST_INDEX crashes server

Detailed revision comments:

r6180 | jyang | 2009-11-17 10:54:57 +0200 (Tue, 17 Nov 2009) | 7 lines
branches/5.0: Merge/Port fix for bug #46000 from branches/5.1
-r5895 to branches/5.0. Disallow creating index with the
name of "GEN_CLUST_INDEX" which is reserved for the default
system primary index. Minor adjusts on table name screening
format for added tests.

Arg_comparator now takes into account that some of
optimizations aren't done in the PREPARE stmt.

BUG#47777 - innodb dies with spatial pk: Failing assertion: buf <= original_buf + buf_len

Detailed revision comments:

r6178 | jyang | 2009-11-17 08:52:11 +0200 (Tue, 17 Nov 2009) | 6 lines
branches/5.0: Merge fix for bug #47777 from branches/5.1 -r6045
to bracnches/5.0. Treat the Geometry data same as Binary BLOB
in ha_innobase::store_key_val_for_row(), since the Geometry
data is stored as Binary BLOB in Innodb.

mysql client displays wrong character-set of server. When a user changes the
charset of a server, mysql client 'status' command displays wrong charset but
the command "SHOW VARIABLES LIKE "%charset%" displayed correct charset results.
The problem is only with the mysql client's 'status' command output.

In mysql client, the method mysql_store_lazy_result() returns 0 for
success and non-zero for failure. The method com_status() was using this method
wrongly. Fixed all such instances according to return value of the method 
mysql_store_lazy_result().

client/mysql.cc:
  Fix for BUG#47671 - wrong character-set after upgrade from 5.1.34 to 5.1.39
  
  Fix com_status() method to use mysql_store_lazy_result() properly.
mysql-test/r/bug47671.result:
  Fix for BUG#47671 - wrong character-set after upgrade from 5.1.34 to 5.1.39
  
  Testcase for BUG#47671
mysql-test/t/bug47671-master.opt:
  Fix for BUG#47671 - wrong character-set after upgrade from 5.1.34 to 5.1.39
  
  Testcase for BUG#47671
mysql-test/t/bug47671.test:
  Fix for BUG#47671 - wrong character-set after upgrade from 5.1.34 to 5.1.39
  
  Testcase for BUG#47671