When compiling INSERT statements the check whether columns are provided values
depends on the flag whether a field is used in that query (Field::query_id).
However the check for updatability of VIEW columns (check_view_insertability())
was calling fix_fields() and thus setting the Field::query_id even for the 
view fields that are not referenced in the current INSERT statement.
So the correct check for columns without default values 
( check_that_all_fields_are_given_values() ) is assuming that all the VIEW
columns were mentioned in the INSERT field list and was issuing no 
warnings or errors.
Fixed check_view_insertability() to turn off the flag whether or not to set
Field::query_id (THREAD::set_query_id) before calling fix fields and restore
it when it's done.

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

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. 

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

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.

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

execution plans in 4.1 and 5.0.

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

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

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

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

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.

into  mysql.com:/home/bk/fix-mysql-5.0

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

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

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

            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.

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

Backport Valgrind suppression from mysql-5.1:

D 1.4 05/11/23 22:44:54+02:00 monty@mysql.com 5 4 12/0/154
P mysql-test/valgrind.supp
C Remove warning that may happens becasue threads dies in different order

into  mysql.com:/home/kgeorge/mysql/5.0/B18080

into  mysql.com:/home/marty/MySQL/mysql-5.0

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

into  mysql.com:/home/kgeorge/mysql/5.0/B20482

            schemas
The function check_one_table_access() called to check access to tables in 
SELECT/INSERT/UPDATE was doing additional checks/modifications that don't hold
in the context of setup_tables_and_check_access().
That's why the check_one_table() was split into two : the functionality needed by
setup_tables_and_check_access() into check_single_table_access() and the rest of 
the functionality stays in check_one_table_access() that is made to call the new
check_single_table_access() function.

into  mysql.com:/home/marty/MySQL/mysql-5.0

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

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

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

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.

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

  Additional fix for #16377 for bigendian platforms
sql_select.cc, select.result, select.test:
  After merge fix