into  moonbone.local:/mnt/gentoo64/work/27033-bug-5.0-opt-mysql

touched but not actually changed.

The LAST_INSERT_ID() is reset to 0 if no rows were inserted or changed.
This is the case when an INSERT ... ON DUPLICATE KEY UPDATE updates a row
with the same values as the row contains.

Now the LAST_INSERT_ID() values is reset to 0 only if there were no rows
successfully inserted or touched.
The new 'touched' field is added to the COPY_INFO structure. It holds the
number of rows that were touched no matter whether they were actually
changed or not.

into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt

into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt

into  mysql.com:/home/kent/bk/tmp/mysql-5.0-build

into  mysql.com:/home/kent/bk/tmp/mysql-4.1-build

  Updated to version 0.6 of the text

into  mysql.com:/home/kent/bk/tmp/mysql-5.0-build

into  mysql.com:/home/kent/bk/tmp/mysql-5.0-build

into  mysql.com:/home/kent/bk/tmp/mysql-4.1-build

into  mysql.com:/home/kent/bk/tmp/mysql-4.1-build

  Added test for sched_yield() possibly in -lposix4 on Solaris

into  magare.gmz:/home/kgeorge/mysql/autopush/B26794-5.0-opt

Different set of conditions is used to verify
the validity of index definitions over a GEOMETRY
column in ALTER TABLE and CREATE TABLE. 
The difference was on how sub-keys notion validity
is checked.
Fixed by extending the CREATE TABLE condition to
support the cases allowed in ALTER TABLE.
Made the SHOW CREATE TABLE not to display spatial
indexes using the sub-key notion.

into  magare.gmz:/home/kgeorge/mysql/autopush/B26672-5.0-opt

into  mysql.com:/home/svoj/devel/mysql/BUG26881/mysql-5.0-engines

            differences in tables
Certain merge tables were wrongly reported as having incorrect definition:
- Some fields that are 1 byte long (e.g. TINYINT, CHAR(1)), might
  be internally casted (in certain cases) to a different type on a
  storage engine layer. (affects 4.1 and up)
- If tables in a merge (and a MERGE table itself) had short VARCHAR column (less
  than 4 bytes) and at least one (but not all) tables were ALTER'ed (even to an
  identical table: ALTER TABLE xxx ENGINE=yyy), table definitions went ouf of
  sync. (affects 4.1 only)

This is fixed by relaxing a check for underlying conformance and setting
field type to FIELD_TYPE_STRING in case varchar is shorter than 4
when a table is created.

into  mysql.com:/home/svoj/devel/mysql/BUG26881/mysql-5.0-engines

into  mysql.com:/home/svoj/devel/mysql/BUG26881/mysql-5.0-engines

into  mysql.com:/home/svoj/devel/mysql/BUG26881/mysql-4.1-engines

into  mysql.com:/home/kent/bk/tmp/mysql-5.0-build

into  mysql.com:/home/kent/bk/tmp/mysql-5.0-build

  Restored accidently removed line to check for zlib

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

  Removed references to my_winsem.c

into  mysql.com:/home/kent/bk/tmp/mysql-5.0-build

  Removed references to unused files

into  mysql.com:/home/kent/bk/tmp/mysql-4.1-build

  Removed unused files
.del-my_winsem.c:
  Delete: mysys/my_winsem.c
.del-my_semaphore.c:
  Delete: mysys/my_semaphore.c
.del-my_semaphore.h:
  Delete: include/my_semaphore.h

into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug26963

into  ymer.(none):/usr/local/mysql/mysql-5.0-ndb

when the column is to be read from a derived table column which 
was specified as a concatenation of string literals.
The bug happened because the Item_string::append did not adjust the
value of Item_string::max_length. As a result of it the temporary 
table column  defined to store the concatenation of literals was 
not wide enough to hold the whole value.

after single-row table substitution could lead to a wrong result set.
The bug happened because the function Item_field::replace_equal_field
erroniously assumed that any field included in a multiple equality
with a constant has been already substituted for this constant.
This not true for fields becoming constant after row substitutions
for constant tables.
 

into  magare.gmz:/home/kgeorge/mysql/autopush/WL3527-5.0-opt-merge

into  moonbone.local:/mnt/gentoo64/work/25373-bug-5.0-opt-mysql

When the SUBSTRING() function was used over a LONGTEXT field the max_length of
the SUBSTRING() result was wrongly calculated and set to 0. As the max_length
parameter is used while tmp field creation it limits the length of the result
field and leads to printing an empty string instead of the correct result.

Now the Item_func_substr::fix_length_and_dec() function correctly calculates
the max_length parameter.

into  moonbone.local:/mnt/gentoo64/work/25373-bug-5.0-opt-mysql

into  chilla.local:/home/mydev/mysql-4.1-bug25673