into  dator5.(none):/home/pappa/push_clone

into  bodhi.local:/opt/local/work/mysql-5.1-runtime-merge

into  dator5.(none):/home/pappa/bug21388

into  dator5.(none):/home/pappa/bug21388

Review fixes

into  bk-internal.mysql.com:/data0/bk/mysql-5.1-kt

CMake versions > 2.4 allow linking to STATIC or SHARED libraries only.

skip engine handling if engine is disabled

into  bodhi.local:/opt/local/work/mysql-5.1-runtime-merge

doesn't find the column"

When a user was using 4.1 tables with VARCHAR column and 5.0 server
and a query that used a temporary table to resolve itself, the
table metadata for the varchar column sent to client was incorrect:
MYSQL_FIELD::table member was empty.

The bug was caused by implicit "upgrade" from old VARCHAR to new
VARCHAR hard-coded in Field::new_field, which did not preserve
the information about the original table. Thus, the field metadata
of the "upgraded" field pointed to an auxiliary temporary table
created for query execution.

The fix is to copy the pointer to the original table to the new field.

into  bk-internal.mysql.com:/data0/bk/mysql-5.1-kt

into  lamia.home:/home/timka/mysql/src/5.1-bug-21456

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug17591

  - BUG#15934: Instance manager fails to work;
  - BUG#18020: IM connect problem;
  - BUG#18027: IM: Server_ID differs;
  - BUG#18033: IM: Server_ID not reported;
  - BUG#21331: Instance Manager: Connect problems in tests;

The only test suite has been changed
(server codebase has not been modified).

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug17591

When a view was used inside a trigger or a function, lock type for
tables used in a view was always set to READ (thus making the view
non-updatable), even if we were trying to update the view.

The solution is to set lock type properly.

into  bk-internal.mysql.com:/data0/bk/mysql-5.1-kt

into  dator5.(none):/home/pappa/bug21388

into  zim.(none):/home/brian/mysql/arch-5.1

into  zim.(none):/home/brian/mysql/arch-5.1

Fixed "discover" in the handler API.

Fixed problem where handlerton was not zero'ed. I need to look around, I suspect this problem is more widespread. 

into  example.com:/work/mysql-5.0-runtime

erroneous check

Problem: Actually there were two problems in the server code. The check
for SQLCOM_FLUSH in SF/Triggers were not according to the existing
architecture which uses sp_get_flags_for_command() from sp_head.cc .
This function was also missing a check for SQLCOM_FLUSH which has a
problem combined with prelocking. This changeset fixes both of these
deficiencies as well as the erroneous check in
sp_head::is_not_allowed_in_function() which was a copy&paste error.

into  alik.:/mnt/raid/alik/MySQL/devel/5.0-rt-bug16899

into  bk-internal.mysql.com:/data0/bk/mysql-5.1-kt

The following procedure was not possible if max_sp_recursion_depth is 0
create procedure show_proc() show create procedure show_proc;
  
Actually there is no recursive call but the limit is checked.
  
Solved by temporarily increasing the thread's limit just before the fetch from cache
and decreasing after that.

Changed trigger-handling code so that there will be the one
place for generate statement string for replication log
and for trigger file.

into  mysql.com:/home/cps/mysql/trees/mysql-5.1-virgin

Changes in an item tree done by optimizer weren't properly
registered and went unnoticed, which resulted in preliminary freeing
of used memory.

  
User name (host name) has limit on length. The server code relies on these
limits when storing the names. The problem was that sometimes these limits
were not checked properly, so that could lead to buffer overflow.

The fix is to check length of user/host name in parser and if string is too
long, throw an error.

into  lamia.home:/home/timka/mysql/src/5.0-bug-21456