into  bk-internal.mysql.com:/data0/bk/mysql-5.0-cmake

into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-ndb

into  shellback.(none):/home/msvensson/mysql/mysql-5.0-maint

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

into  maint2.mysql.com:/data/localhome/tsmith/bk/50

into  maint2.mysql.com:/data/localhome/tsmith/bk/50

into  maint2.mysql.com:/data/localhome/tsmith/bk/bfx/50

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

into  maint2.mysql.com:/data/localhome/tsmith/bk/bfx/41

into  mysql.com:/Users/kent/mysql/bk/mysql-5.0

into  mysql.com:/Users/kent/mysql/bk/mysql-5.0

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint

 - Use the "%.*b" format when printing prepared and exeuted prepared statements to the log.
 - Add test case to check that also prepared statements end up in the query log
Bug#14346 Prepared statements corrupting general log/server memory
 - Use "stmt->query" when logging the newly prepared query instead of "packet"

  Auto merged

into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-ndb

into  mysql.com:/Users/kent/mysql/bk/mysql-5.0

length limit", it's superseded by the fix for Bug#16899 "Possible buffer
overflow in handling of DEFINER-clause". Update test results.

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

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.0-kt

into  polly.local:/home/kaa/src/maint/m50-maint--07OGt

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.

    
init_dumping now accepts a function pointer to the table or view specific init_dumping function.  This allows both tables and views to use the init_dumping function.

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

into  dl145s.mysql.com:/data/tkatchaounov/autopush/5.0-bug-21456

into  moonbone.local:/work/tmp_merge-5.0-mysql