After merge fix

into  chilla.local:/home/mydev/mysql-4.1-bug20719


myisam/mi_dynrec.c:
  Bug#20719 - Reading dynamic records with write buffer could fail
  Manual merge

into  chilla.local:/home/mydev/mysql-4.1

Fixed a possible problem with reading of dynamic records
when a write cache is active. The cache must be flushed
whenever a part of the file in the write cache is to be 
read.

Added a read optimization to _mi_read_dynamic_record().

No test case. This was a hypothetical but existing problem.


myisam/mi_dynrec.c:
  Bug#20719 - Reading dynamic records with write buffer could fail
  
  Fixed a possible problem with reading of dynamic records
  when a write cache is active. The cache must be flushed
  whenever a part of the file in the write cache is to be 
  read. This must be done before the read of the header
  and before the read of the rest block.
  
  Renamed the 'flag' and 'skipp_deleted_blocks' variables.
  
  Added a read optimization to _mi_read_dynamic_record()
  that was present in _mi_read_rnd_dynamic_record() already.
  After _mi_get_block_info() we have some bytes of the record
  in the header buffer already. No need to read them again.

closing temp tables through end_thread
had a flaw in binlog-off branch of close_temporary_tables where
next table to close was reset via table->next
 for (table= thd->temporary_tables; table; table= table->next)
which was wrong since the current table instance got destoyed at
	close_temporary(table, 1);

The fix adapts binlog-on branch method to engage the loop's internal 'next' variable which holds table->next prior table's destoying.



sql/sql_base.cc:
  no-binlog branch is fixed: scanning across temporary_tables must be careful to save next table since the current is being destroyed inside of close_temporary. 
  binlog-is-open case is ok.

into  mysql.com:/home/mydev/mysql-4.1-bug14400


myisam/mi_rkey.c:
  Bug#14400 - Query joins wrong rows from table which is subject of "concurrent insert"
  Manual merge
sql/sql_class.cc:
  Bug#14400 - Query joins wrong rows from table which is subject of "concurrent insert"
  Manual merge

It was possible that fetching a record by an exact key value 
(including the record pointer) could return a record with a 
different key value. This happened only if a concurrent insert 
added a record with the searched key value after the fetching 
statement locked the table for read.

The search succeded on the key value, but the record was
rejected as it was past the file length that was remembered
at start of the fetching statement. With other words it was 
rejected as being a concurrently inserted record.

The action to recover from this problem was to fetch the 
record that is pointed at by the next key of the index. 
This was repeated until a record below the file length was 
found.

I do now avoid this loop if an exact match was searched. 
If this match is beyond the file length, it is now treated 
as "key not found". There cannot be another key with the 
same record pointer.


myisam/mi_rkey.c:
  Bug#14400 - Query joins wrong rows from table which is subject of "concurrent insert"
  Added a check for exact key match before searching for
  the next key that was not concurrently inserted. If an
  exact key match finds a concurrently inserted row, this
  must be treated as "key not found".
sql/sql_class.cc:
  Bug#14400 - Query joins wrong rows from table which is subject of "concurrent insert"
  Fixed some DBUG_ENTER strings.

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.


mysql-test/r/symlink.result:
  Modified test result according to fix for BUG#1662.
sql/sql_parse.cc:
  Produce a warning if DATA/INDEX DIRECTORY is specified in
  ALTER TABLE statement.

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


mysql-test/r/func_sapdb.result:
  test cases for date range edge cases added
mysql-test/r/func_time.result:
  test cases for date range edge cases added
mysql-test/t/func_sapdb.test:
  test cases for date range edge cases added
mysql-test/t/func_time.test:
  test cases for date range edge cases added

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

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


scripts/make_binary_distribution.sh:
  Auto merged
scripts/make_sharedlib_distribution.sh:
  Auto merged

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


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

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


sql/sql_parse.cc:
  Auto merged

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

  An UNIQUE KEY consisting of NOT NULL columns
  was displayed as PRIMARY KEY in "DESC t1".
  According to the code, that was intentional
  behaviour for some reasons unknown to me.
  This code was written before bitkeeper time,
  so I cannot check who and why made this.
  After discussing on dev-public, a decision
  was made to remove this code


mysql-test/r/key.result:
  Adding test case.
mysql-test/t/key.test:
  Adding test case.
sql/table.cc:
  Removing old wrong code

  Disable the simplistic auto dependency scan for test/bench (bug#20078)


support-files/mysql.spec.sh:
  Disable the simplistic auto dependency scan for test/bench (bug#20078)

The AsBinary function returns VARCHAR data type with binary collation.
It can cause problem for clients that treat that kind of data as
different from BLOB type.
So now AsBinary returns BLOB.


mysql-test/r/gis.result:
  result fixed
mysql-test/t/gis.test:
  test case added
sql/item_geofunc.h:
  Now we return MYSQL_TYPE_BLOB for asBinary function

into moonbone.local:/work/tmp_merge-4.1-opt-mysql

This bug in Field_string::cmp resulted in a wrong comparison 
with keys in partial indexes over multi-byte character fields.
Given field a is declared as a varchar(16) collate utf8_unicode_ci
INDEX(a(4)) gives us an example of such an index.
  
Wrong key comparisons could lead to wrong result sets if 
the selected query execution plan used a range scan by 
a partial index over a utf8 character field.
This also caused wrong results in many other cases.


mysql-test/t/ctype_utf8.test:
  Added test cases for bug #14896.
mysql-test/r/ctype_utf8.result:
  Added test cases for bug #14896.
sql/field.cc:
  Fixed bug #14896.
  This bug in Field_string::cmp resulted in a wrong comparison 
  with keys in partial indexes over multi-byte character fields.
  Given field a is declared as a varchar(16) collate utf8_unicode_ci
  INDEX(a(4)) gives us an example of such an index.
       
  Wrong key comparisons could lead to wrong result sets if 
  the selected query execution plan used a range scan by 
  a partial index over a utf8 character field.
  This also caused wrong results in many other cases.

into  may.pils.ru:/home/svoj/devel/mysql/BUG20357/mysql-4.1

into  may.pils.ru:/home/svoj/devel/mysql/BUG20357/mysql-4.1


sql/opt_sum.cc:
  Auto merged
mysql-test/r/myisam.result:
  SCCS merged
mysql-test/t/myisam.test:
  SCCS merged

            functions in queries

Using MAX()/MIN() on table with disabled indexes (by ALTER TABLE)
results in error 124 (wrong index) from storage engine.

The problem was that optimizer use disabled index to optimize
MAX()/MIN(). Normally it must skip disabled index and perform
table scan.

This patch skips disabled indexes for min/max optimization.


mysql-test/r/myisam.result:
  Test case for BUG#20357.
mysql-test/t/myisam.test:
  Test case for BUG#20357.
sql/opt_sum.cc:
  Skip disabled/ignored indexes for min/max optimization.

into moonbone.local:/work/tmp_merge-4.1-opt-mysql

  Added test case for bug#18759 Incorrect string to numeric conversion.  
select.test:
  Added test case for bug#18759 Incorrect string to numeric conversion.
item_cmpfunc.cc:
  Cleanup after fix for bug#18360 removal


sql/item_cmpfunc.cc:
  Cleanup after fix for bug#18360 removal
mysql-test/t/select.test:
  Added test case for bug#18759 Incorrect string to numeric conversion.
mysql-test/r/select.result:
  Added test case for bug#18759 Incorrect string to numeric conversion.

into  mysql.com:/usr/home/ram/work/mysql-4.1


mysql-test/r/func_str.result:
  merge (ul)
mysql-test/t/func_str.test:
  merge (ul)
sql/item_strfunc.cc:
  merge (ul)
sql/item_strfunc.h:
  merge (ul)

into  mysql.com:/usr/home/ram/work/mysql-4.1

into  mysql.com:/users/lthalmann/bk/MERGE/mysql-4.1-merge

into moonbone.local:/work/tmp_merge-4.1-opt-mysql

into moonbone.local:/work/tmp_merge-4.1-opt-mysql

  Reverted fix for bug#18360


mysql-test/t/func_in.test:
  Reverted fix for bug#18360
mysql-test/r/func_in.result:
  Reverted fix for bug#18360
sql/item_cmpfunc.cc:
  Reverted fix for bug#18360

there was two problems about charsets in embedded server
1. mysys/charset.c - defined there default_charset_info variable is
modified by both server and client code (particularly when
--default-charset option is handled)
In embedded server we get two codelines modifying one variable.
I created separate default_client_charset_info for client code

2. mysql->charset and mysql->options.charset initialization isn't
properly done for embedded server - necessary calls added


include/sql_common.h:
  client charset info default declared
libmysqld/lib_sql.cc:
  thd_init_client_charset calls added
libmysqld/libmysqld.c:
  check_embedded_connection moved to client.c to avoid code duplication
sql-common/client.c:
  charset initialization moved to mysql_init_character_set to
  be used in embedded server
sql/sql_parse.cc:
  thread client charset initialization moved to thd_init_client_charset
  to avoid code duplication

into  mysql.com:/home/kgeorge/mysql/4.1/B9676

              tables
Currently in INSERT ... SELECT ... LIMIT ... the compiler uses a 
temporary table to store the results of SELECT ... LIMIT .. and then
uses that table as a source for INSERT. The problem is that in some cases
it actually skips the LIMIT clause in doing that and materializes the 
whole SELECT result set regardless of the LIMIT.
This fix is limiting the process of filling up the temp table with only 
that much rows that will be actually used by propagating the LIMIT value.


mysql-test/r/insert_select.result:
  * Bug #9676: INSERT INTO x SELECT .. FROM x LIMIT 1; slows down with big
                tables
  - a test demonstrating the code path
mysql-test/t/insert_select.test:
  * Bug #9676: INSERT INTO x SELECT .. FROM x LIMIT 1; slows down with big
                tables
  - a test demonstrating the code path
sql/sql_select.cc:
  * Bug #9676: INSERT INTO x SELECT .. FROM x LIMIT 1; slows down with big
                tables
  - pass through the real LIMIT number if the temp table is created for
    buffering results.
  - set the counter for all the cases when the temp table is not used for
    grouping

into  mysql.com:/users/lthalmann/bk/MERGE/mysql-4.1-merge

into  may.pils.ru:/home/svoj/devel/mysql/BUG18036/mysql-4.1

Certain updates of table joined to self results in unexpected
behavior.

The problem was that record cache was mistakenly enabled for
self-joined table updates. Normally record cache must be disabled
for such updates.

Fixed wrong condition in code that determines whether to use
record cache for self-joined table updates.

Only MyISAM tables were affected.


mysql-test/r/myisam.result:
  Test case for BUG#18036.
mysql-test/t/myisam.test:
  Test case for BUG#18036.
sql/sql_update.cc:
  Fixed wrong condition in code that determines whether to use
  record cache for self-joined table updates.

mysql-test/r/func_time.result:
  Fix for bug #20496: func_time.test failure                                      
    - floating point calculations removed.
mysql-test/t/func_time.test:
  Fix for bug #20496: func_time.test failure                                      
    - floating point calculations removed.

into moonbone.local:/work/tmp_merge-4.1-opt-mysql