into  mysql.com:/home/mydev/mysql-5.0-bug11824

into  mysql.com:/home/mydev/mysql-5.0-bug11824

into  mysql.com:/home/mydev/mysql-5.0-bug11824

into  mysql.com:/home/jimw/my/mysql-5.0-16494

Pushbuild fixes to result file, test, and header file for federated.

into  xiphis.org:/home/antony/work2/mysql-5.0-engines.sync

into  govinda.patg.net:/home/patg/mysql-build/mysql-5.0-engines-bug19773

into  xiphis.org:/home/antony/work2/p4-bug12096.2-merge

CHECK TABLE could complain about a fully intact spatial index.
A wrong comparison operator was used for table checking. 
The result was that it checked for non-matching spatial keys. 
This succeeded if at least two different keys were present, 
but failed if only the matching key was present.

I fixed the key comparison.

into  mysql.com:/home/tnurnberg/mysql-5.0

into  mysql.com:/home/tnurnberg/mysql-5.0

  
sp_grant_privileges(), the function that GRANTs EXECUTE + ALTER privs on a SP,
did so creating a user-entry with not password; mysql_routine_grant() would then
write that "change" to the user-table.

into mysql.com:/home/gluh/MySQL/Merge/5.0-kt

  
Final-review fixes per Monty, pre-push. OK'd for 
push. Please see each file's comments.

into  poseidon.ndb.mysql.com:/home/tomas/mysql-5.0-main

into mysql.com:/M50/autopush20216-5.0

into  poseidon.ndb.mysql.com:/home/tomas/mysql-5.0-main

This finishes bug#18516, as far as "generic RPMs" are concerned.

Produce a warning if DATA/INDEX DIRECTORY is specified in
ALTER TABLE statement.

Ignoring of these options is documented in the symbolic links
section of the manual.

manual merge from 4.0.

Dec. 31st, 9999 is still a valid date, only starting with Jan 1st 10000 things become invalid (Bug #12356)

into  poseidon.ndb.mysql.com:/home/tomas/mysql-5.0-main

Fix a minor issue with Bug#16206 (bdb.test failed if the tree is compiled 
without blackhole).

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

Very complex select statements can create temporary tables
that are too big to be represented as a MyISAM table.

This was not checked at table creation time, but only at
open time. The result was an attempt to delete the 
"impossible" table.

But if the server is built --with-raid, MyISAM tries to 
open the table before deleting the files. It needs to find 
out if the table uses the raid support and how many raid 
chunks there are. This is done with an open "for repair",
which will almost always succeed.

But in this case we have an "impossible" table. The open
failed. Hence the files were not deleted. Also the error
message was a bit unspecific.

I turned an open error in this situation into the assumption 
of having no raid support on the table. Thus the normal data 
file is tried to be deleted. This may however leave existing 
raid chunks behind.

I also added a check in mi_create() to prevent the creation
of an "impossible" table. A more decriptive error message is
given in this case.

No test case. The required select statement is way too
large for the test suite. I added a test script to the
bug report.

- correction of previous patch

- make sure to allocate just enough pages in the fragments by using the actual
  row count from the backup, to avoid over allocation of pages to fragments, and
  thus avoid the bug

 When building the UPDATE query to send to the remote server, the
 federated storage engine built the query incorrectly if it was updating
 a field to be NULL.

 Thanks to Bjšrn Steinbrink for an initial patch for the problem.

into  mysql.com:/opt/local/work/mysql-5.0-17199

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

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

into mysql.com:/Users/kent/mysql/bk/mysql-4.1-new

  For compatibility, don't use {..,..} in pattern matching
make_binary_distribution.sh:
  Added .dylib and .sl as shared library extensions