into  moonbone.local:/work/18503-bug-4.1-mysql


sql/sql_select.cc:
  Auto merged

may return a wrong result.

An Item_sum_hybrid object has the was_values flag which indicates whether any
values were added to the sum function. By default it is set to true and reset
to false on any no_rows_in_result() call. This method is called only in
return_zero_rows() function. An ALL/ANY subquery can be optimized by MIN/MAX
optimization. The was_values flag is used to indicate whether the subquery
has returned at least one row. This bug occurs because return_zero_rows() is
called only when we know that the select will return zero rows before
starting any scans but often such information is not known.
In the reported case the return_zero_rows() function is not called and
the was_values flag is not reset to false and yet the subquery return no rows
Item_func_not_all and Item_func_nop_all functions return a wrong
comparison result.

The end_send_group() function now calls no_rows_in_result() for each item
in the fields_list if there is no rows were found for the (sub)query.


mysql-test/t/subselect.test:
  Added test case for bug#18503: Queries with a quantified subquery returning empty set may return a wrong result.
mysql-test/r/subselect.result:
  Added test case for bug#18503: Queries with a quantified subquery returning empty set may return a wrong result.
sql/sql_select.cc:
  Fixed bug#18503: Queries with a quantified subquery returning empty set may return a wrong result.
  
  The end_send_group() function now calls no_rows_in_result() for each item
  in the fields_list if there is no matching rows were found.

into  macbook.gmz:/Users/kgeorge/mysql/work/B14553-4.1-opt


sql/sql_class.cc:
  SCCS merged
sql/sql_select.cc:
  SCCS merged

To make MySQL compatible with some ODBC applications, you can find
the AUTO_INCREMENT value for the last inserted row with the following query:
 SELECT * FROM tbl_name WHERE auto_col IS NULL.
This is done with a special code that replaces 'auto_col IS NULL' with
'auto_col = LAST_INSERT_ID'.
However this also resets the LAST_INSERT_ID to 0 as it uses it for a flag
so as to ensure that only the first SELECT ... WHERE auto_col IS NULL
after an INSERT has this special behaviour.
In order to avoid resetting the LAST_INSERT_ID a special flag is introduced
in the THD class. This flag is used to restrict the second and subsequent
SELECTs instead of LAST_INSERT_ID.


mysql-test/r/odbc.result:
  test suite for the bug
mysql-test/r/rpl_insert_id.result:
  test for the fix in replication
mysql-test/t/odbc.test:
  test suite for the bug
mysql-test/t/rpl_insert_id.test:
  test for the fix in replication
sql/sql_class.cc:
  initialize the flag
sql/sql_class.h:
  flag's declaration and set code when setting the last_insert_id
sql/sql_select.cc:
  the special flag is used instead of last_insert_id

into  olga.mysql.com:/home/igor/mysql-4.1-opt

The implementation of the method Item_func_reverse::val_str
for the REVERSE function modified the argument of the function.
This led to wrong results for expressions that contained
REVERSE(ref) if ref occurred somewhere else in the expressions.


mysql-test/r/func_str.result:
  Added a test case for bug #18243.
mysql-test/t/func_str.test:
  Added a test case for bug #18243.
sql/item_strfunc.cc:
  Fixed bug #18243.
  The implementation of the method Item_func_reverse::val_str
  for the REVERSE function modified the argument of the function.
  This led to wrong results for expressions that contained
  REVERSE(ref) if ref occurred somewhere else in the expressions.
  
  The implementation of Item_func_reverse::val_str has been changed
  to make the argument intact.
sql/item_strfunc.h:
  Fixed bug #18243.
  Added tmp_value to the Item_func_reverse class to store
  the result of the function. It erroneously replaced the 
  argument before this fix.

into moonbone.local:/work/merge-4.1

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

into  mysql.com:/home/stewart/Documents/MySQL/4.1/main

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

sql/item_cmpfunc.h:
  gcc 4.1 linux warning fixes backported from 5.0
sql/opt_range.cc:
  gcc 4.1 linux warning fixes.
sql/spatial.h:
  gcc 4.1 linux warning fixes backported from 5.0
sql/sql_select.h:
  gcc 4.1 linux warning fixes.
sql/sql_update.cc:
  gcc 4.1 linux warning fixes.

into  mysql.com:/home/stewart/Documents/MySQL/4.1/merge

change default minimum to 3

bug is *very* timing dependent, unable to reproduce here, but theoretically possible.


ndb/src/mgmsrv/ConfigInfo.cpp:
  change minimum NoOfFragmentLogFiles to 3

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.

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

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

'SELECT DISTINCT a,b FROM t1' should not use temp table if there is unique 
index (or primary key) on a.
There are a number of other similar cases that can be calculated without the
use of a temp table : multi-part unique indexes, primary keys or using GROUP BY 
instead of DISTINCT.
When a GROUP BY/DISTINCT clause contains all key parts of a unique
index, then it is guaranteed that the fields of the clause will be
unique, therefore we can optimize away GROUP BY/DISTINCT altogether.
This optimization has two effects:
* there is no need to create a temporary table to compute the
   GROUP/DISTINCT operation (or the temporary table will be smaller if only GROUP 
   is removed and DISTINCT stays or if DISTINCT is removed and GROUP BY stays)
* this causes the statement in effect to become updatable in Connector/Java
because the result set columns will be direct reference to the primary key of 
the table (instead to the temporary table that it currently references). 

Implemented a check that will optimize away GROUP BY/DISTINCT for queries like 
the above.
Currently it will work only for single non-constant table in the FROM clause.


mysql-test/r/distinct.result:
  Bug #16458: Simple SELECT FOR UPDATE causes "Result Set not updatable" error
    - test case
mysql-test/t/distinct.test:
  Bug #16458: Simple SELECT FOR UPDATE causes "Result Set not updatable" error
    - test case
sql/sql_select.cc:
  Bug #16458: Simple SELECT FOR UPDATE causes "Result Set not updatable" error
    - disable GROUP BY if contains the fields of a unique index.

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

This was another manifestation of the problems fixed in the
patch for bug 16674.
Wrong calculation of length of the search prefix in the pattern
string led here to a wrong result set for a query in 4.1. 
The bug could be demonstrated for any multi-byte character set. 


mysql-test/r/ctype_utf8.result:
  Added a test case for bug #18359.
mysql-test/t/ctype_utf8.test:
  Added a test case for bug #18359.

Server crashed in some cases when a query required a MIN/MAX
agrregation for a 'ucs2' field. 
In these cases  the aggregation caused calls of the function
update_tmptable_sum_func that indirectly invoked 
the method Item_sum_hybrid::min_max_update_str_field() 
containing a call to strip_sp for a ucs2 character set.
The latter led directly to the crash as it used my_isspace
undefined for the ucs2 character set.
Actually the call of strip_sp is not needed at all in this
situation and has been removed by the fix.


mysql-test/r/ctype_ucs.result:
  Added a test case for bug #20076.
mysql-test/t/ctype_ucs.test:
  Added a test case for bug #20076.

  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

execution plans in 4.1 and 5.0.

into  rurik.mysql.com:/home/igor/mysql-4.1-opt


mysql-test/r/ctype_utf8.result:
  SCCS merged
mysql-test/t/ctype_utf8.test:
  SCCS merged

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  rurik.mysql.com:/home/igor/mysql-4.1-opt

The length of the prefix of the pattern string in the LIKE predicate that 
determined the index range to be scanned was calculated incorrectly for
multi-byte character sets. 
As a result of this in 4. 1 the the scanned range was wider then necessary
if the prefix contained not only one-byte characters.  
In 5.0 additionally it caused missing some rows from the result set.


mysql-test/r/ctype_utf8.result:
  Added test cases for bug #16674.
mysql-test/t/ctype_utf8.test:
  Added test cases for bug #16674.
strings/ctype-mb.c:
  Fixed bug #16674.
  The length of the prefix of the pattern string in the LIKE predicate that 
  determined the index range to be scanned was calculated incorrectly for
  multi-byte character sets. 
  As a result of this in 4. 1 the the scanned range was wider then necessary
  if the prefix contained not only one-byte characters.  
  In 5.0 additionally it caused missing some rows from the result set.
      
  The function my_like_range_mb was fixed to calculate the length of
  the prefix in a pattern string correctly in all cases.

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