Bug#4968 "Stored procedure crash if cursor opened on altered table"
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from 
stored procedure."
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"

Test cases for bugs 4968, 19733, 6895 will be added in 5.0.

Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE 
statements in stored routines or as prepared statements caused
incorrect results (and crashes in versions prior to 5.0.25).
In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).

The problem of bugs 4968, 19733, 19282 and 6895 was that functions
mysql_prepare_table, mysql_create_table and mysql_alter_table were not
re-execution friendly: during their operation they used to modify contents
of LEX (members create_info, alter_info, key_list, create_list),
thus making the LEX unusable for the next execution.
In particular, these functions removed processed columns and keys from
create_list, key_list and drop_list. Search the code in sql_table.cc 
for drop_it.remove() and similar patterns to find evidence.

The fix is to supply to these functions a usable copy of each of the
above structures at every re-execution of an SQL statement. 

To simplify memory management, LEX::key_list and LEX::create_list
were added to LEX::alter_info, a fresh copy of which is created for
every execution.

The problem of crashing bug 22060 stemmed from the fact that the above 
metnioned functions were not only modifying HA_CREATE_INFO structure in 
LEX, but also were changing it to point to areas in volatile memory of 
the execution memory root.
 
The patch solves this problem by creating and using an on-stack
copy of HA_CREATE_INFO (note that code in 5.1 already creates and
uses a copy of this structure in mysql_create_table()/alter_table(),
but this approach didn't work well for CREATE TABLE SELECT statement).

into  bodhi.local:/opt/local/work/mysql-4.1-runtime

into  kahlann.erinye.com:/home/df/mysql/build/mysql-4.1-build-work

into  bodhi.local:/opt/local/work/mysql-4.1-runtime

  If using \$(srcdir)/mysql.info in action, use same in rule.

into  mysql.com:/home/kent/bk/mysql-4.1-merge

  BSD compatibility

  Fix undefined behaviour.
Many files:
  Reenabled build outside ource tree

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-4.1-bug21635

expression cols.

The problem was that MYSQL_FIELD::org_name was set for MIN() and MAX()
functions (COUNT() is also mentioned in the bug report but was already
fixed).

After this patch for expressions MYSQL_FIELD::name is set to either
expression itself or its alias, and other data origin fields of
MYSQL_FILED (db, org_table, table, org_name) are empty strings.

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-4.1-bug23159

Make Prepared_stmt_count a global status variable, accessible via
SHOW STATUS LIKE 'Prepared_stmt_count';.  Documentation should be
updated.

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-4.1-bug23383

mysql_stmt_affected_rows()

The problem was that affected_rows for prepared statement wasn't updated
in the client library on the error.  The solution is to always update
affected_rows, which will be equal to -1 on the error.

into  trift2.:/MySQL/M41/push-4.1

into  mysql.com:/home/hf/work/mysql-4.1-mrg

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-4.1-bug17047

The problem was that some functions (namely IN() starting with 4.1, and
CHAR() starting with 5.0) were returning NULL in certain conditions,
while they didn't set their maybe_null flag.  Because of that there could
be some problems with 'IS NULL' check, and statements that depend on the
function value domain, like CREATE TABLE t1 SELECT 1 IN (2, NULL);.

The fix is to set maybe_null correctly.

into  mysql.com:/home/bk/MERGE/mysql-4.1-merge

mending windows test.

into  rakia.gmz:/home/kgeorge/mysql/autopush/B19216-4.1-opt

into  mysql.com:/home/bk/MERGE/mysql-4.1-merge

 The server sends a number of columns to the client.
 It uses a limited "fast" function for that instead of the
 general one. This fast function cannot send numbers larger 
 than 2 bytes. 
 This causes the client to expect smaller number of columns. 
 The client writes outside of the allocated memory buffer 
 as a result.
 Fixed the server to use the general function to send column
 count.
 Fixed the client to check the column count before writing
 column data. 

comments are fixed as was suggested in reviews.

bugs/wls in cset's comments. The targetted BUG's or WL's identifier must be specified
the first in the comments. The referred bugs wls can be typed in same as the targeted
clickable format.
If the the target of the fix is a WL and there are some references to bugs
then the first found reference is regarded as "co-target" so that the bug's identifier
comes up on the subject line along with the WL's and commit mail will update
the bug page. The latter feature can be disarmed (if there is no need to update
the referred bug's page) with typing the first a pseudo-bug pattern (bug#0).

This paticular cset will generate subject line containing bug#0 (as it was the first
referred) whereas the old version would put in the subject line the last referred
pattern (e.g bug#2147483648).

  Test for base directory when a RPM install corrected

into  trift2.:/MySQL/M41/push-4.1

into  trift2.:/MySQL/M41/push-4.1

into  kahlann.erinye.com:/home/df/mysql/build/mtr-4.1