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

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.

manual merge from 4.0.

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).

- 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

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

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

 Bug#19022 "Memory bug when switching db during trigger execution"
 Bug#17199 "Problem when view calls function from another database."
 Bug#18444 "Fully qualified stored function names don't work correctly in
            SELECT statements"

 Documentation note: this patch introduces a change in behaviour of prepared
 statements.

 This patch adds a few new invariants with regard to how THD::db should
 be used. These invariants should be preserved in future:

  - one should never refer to THD::db by pointer and always make a deep copy
    (strmake, strdup)
  - one should never compare two databases by pointer, but use strncmp or
    my_strncasecmp
  - TABLE_LIST object table->db should be always initialized in the parser or
    by creator of the object.

    For prepared statements it means that if the current database is changed
    after a statement is prepared, the database that was current at prepare
    remains active. This also means that you can not prepare a statement that
    implicitly refers to the current database if the latter is not set.
    This is not documented, and therefore needs documentation. This is NOT a
    change in behavior for almost all SQL statements except:
     - ALTER TABLE t1 RENAME t2 
     - OPTIMIZE TABLE t1
     - ANALYZE TABLE t1
     - TRUNCATE TABLE t1 --
     until this patch t1 or t2 could be evaluated at the first execution of
     prepared statement. 

     CURRENT_DATABASE() still works OK and is evaluated at every execution
     of prepared statement.

     Note, that in stored routines this is not an issue as the default
     database is the database of the stored procedure and "use" statement
     is prohibited in stored routines.

  This patch makes obsolete the use of check_db_used (it was never used in the
  old code too) and all other places that check for table->db and assign it
  from THD::db if it's NULL, except the parser.

 How this patch was created: THD::{db,db_length} were replaced with a
 LEX_STRING, THD::db. All the places that refer to THD::{db,db_length} were
 manually checked and:
  - if the place uses thd->db by pointer, it was fixed to make a deep copy
  - if a place compared two db pointers, it was fixed to compare them by value
    (via strcmp/my_strcasecmp, whatever was approproate)
 Then this intermediate patch was used to write a smaller patch that does the
 same thing but without a rename.

 TODO in 5.1:
   - remove check_db_used
   - deploy THD::set_db in mysql_change_db

 See also comments to individual files.

into  mysql.com:/nfstmp1/ingo/autopush-75/mysql-5.0

into  mysql.com:/home/alik/MySQL/devel/5.0-rt

into  mysql.com:/home/tnurnberg/review/mysql-5.0-maint-20588

into  mysql.com:/home/mydev/mysql-5.0-bug16986-main

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

into  mysql.com:/home/mydev/mysql-5.0-bug16986-main

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

Addendum fixes after changing the condition variable
for the global read lock.

The stress test suite revealed some deadlocks. Some were
related to the new condition variable (COND_global_read_lock)
and some were general problems with the global read lock.

It is now necessary to signal COND_global_read_lock whenever 
COND_refresh is signalled.

We need to wait for the release of a global read lock if one 
is set before every operation that requires a write lock.
But we must not wait if we have locked tables by LOCK TABLES.
After setting a global read lock a thread waits until all
write locks are released.

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

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

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

into  mysql.com:/data0/bk/mysql-5.0-maint

into  mysql.com:/data0/knielsen/tmp-5.0