Revert fix for this bug as it introduced a regression
reported in Bug#38158.

      
In order to handle CHAR() fields, 8 bits were reserved for
the size of the CHAR field. However, instead of denoting the
number of characters in the field, field_length was used which
denotes the number of bytes in the field.

Since UTF-8 fields can have three bytes per character (and
has been extended to have four bytes per character in 6.0),
an extra two bits have been encoded in the field metadata
work for fields of type Field_string (i.e., CHAR fields).

Since the metadata word is filled, the extra bits have been
encoded in the upper 4 bits of the real type (the most 
significant byte of the metadata word) by computing the
bitwise xor of the extra two bits. Since the upper 4 bits
of the real type always is 1111 for Field_string, this 
means that for fields of length <256, the encoding is
identical to the encoding used in pre-5.1.26 servers, but
for lengths of 256 or more, an unrecognized type is formed,
causing an old slave (that does not handle lengths of 256
or more) to stop.

from 5.0 into the 5.1.26 release clone.

so Apple's internal name ("darwin9") must be translated to ours ("osx10.5").

Bug#35658 (An empty binary value leads to mysqld crash)
  
Before this fix, the following token
  b''
caused the parser to crash when reading the binary value from the empty string.
The crash was caused by:
  ptr+= max_length - 1;
because max_length is unsigned and was 0, causing an overflow.
  
With this fix, an empty binary literal b'' is parsed as a binary value 0,
in Item_bin_string.

Remove unnecessary and incorrect code that tried to pull delimiter commands out of the
middle of statements

                        
      The crash appeared to be a result of allocating an instance of Discrete_interval 
      automatically that that was referred in out-of-declaration scope.
                        
      Fixed with correcting backing up and restoring scheme of
      auto_inc_intervals_forced, introduced by bug#33029, by means of shallow copying;
      added simulation code that forces executing those fixes of the former bug that
      targeted at master-and-slave having incompatible bug#33029-prone versions.

On a slow environment like valgrind the test is vulnerable
because it does not check if slave has stopped at time
of the new session is requested `start slave;' -- disabling
test till it is fixed.

ha_innodb.so was incorrectly installed in the lib/mysql
directory rather than in lib/mysql/plugin.

Amending CS for 31736.

MySQL client crashed if no input was passed to it.

The value of JOIN::tables must be set to 0 when there
is no matching min/max row.

This change was committed to the 5.1.25 release clone, but never
made it to the mysql-5.1 BK tree.  I'm committing it to mysql-5.1
bzr now.

make_binary_distribution.sh got clobbered by the 5.0 version during a merge.
This caused a few packaging problems, including message files put in the wrong
place and some missing files.  Fix is just to revert back to the 5.1 version
from before the merge.

Problem introduced in
ChangeSet 1.2606.2.1 2008/05/13 15:56:07 kent@kent-amd64.(none)

This change was made in the 5.1.25 release clone in BK, but never made it to the main mysql-5.1 BK tree.  I am adding it to mysql-5.1 bzr.

The federated storage engine is now disabled by default.
mysql-test-run.pl is updated to enable it whenever it's required and available.

and table DDL changed after PREPARE" to pass in embedded mode.

the local tree contains a fix for 
Bug#32748 "Inconsistent handling of assignments to 
general_log_file/slow_query_log_file",
which changes output of a number of tests.

after PREPARE"
Update test results after a merge with the main tree: the new minimum for 
the table definition cache is 256.

 PREPARE", review fixes:
- make the patch follow the specification of WL#4166 and remove  
the new error that was originally introduced.
Now the client never gets an error from reprepare, unless it failed.
I.e. even if the statement at hand returns a completely different
result set, this is not considered a server error.
The C API library, that can not handle this situation, was modified to
return a client error.
Added additional test coverage.

into  bodhi.(none):/opt/local/work/mysql-5.1-27430

into  bodhi.(none):/opt/local/work/mysql-5.1-27430

PREPARE": rename members, methods, classes to follow the spec 
(a code review request)

Add test target to the makefile that will cause all
statements to be re-prepared before execution.

into  mysql.com:/d2/hf/mysql-5.1-bugteam

  rpl_innodb_bug28430 disabled

into  host.loc:/work/bk/5.1-bugteam

into  host.loc:/work/bk/5.0-bugteam

                 first row or fails with an error:
  ERROR 1022 (23000): Can't write; duplicate key in table ''

The server uses intermediate temporary table to store updated
row data.  The first column of this table contains rowid.
Current server implementation doesn't reset NULL flag of that
column even if the server fills a column with rowid.
To keep each rowid unique, there is an unique index.
An insertion into an unique index takes into account NULL
flag of key value and ignores real data if NULL flag is set.
So, insertion of actually different rowids may lead to two
kind of problems.  Visible effect of each of these problems
depends on an initial engine type of temporary table:

1. If multiupdate initially creates temporary table as
a MyISAM table (a table contains blob columns, and the
create_tmp_table function assumes, that this table is
large), it inserts only one single row and updates
only rows with one corresponding rowid. Other rows are
silently ignored. 

2. If multiupdate initially creates MEMORY temporary
table, fills it with data and reaches size limit for
MEMORY tables (max_heap_table_size), multiupdate
converts MEMORY table into MyISAM table and fails
with an error:
  ERROR 1022 (23000): Can't write; duplicate key in table ''


Multiupdate has been fixed to update the NULL flag of
temporary table rowid columns.

into  magare.gmz:/home/kgeorge/mysql/work/merge-5.1-bugteam

(Bug#27430)