Do not consider SHOW commands slow queries, just because they don't use proper indexes.

This bug fix is not needed in 5.1, and the code changes will be null merged.  However, the test cases will be propogated up to 5.1.

now takes mbmaxlen into account when calculating max_length of new field. 

The Item::tmp_table_field_from_field_type() function creates Field_datetime
object instead of Field_timestamp object for timestamp field thus always
changing data type is a tmp table is used.

The Field_blob object constructor which is used in the 
Item::tmp_table_field_from_field_type() is always setting packlength field of
newly created blob to 4. This leads to changing fields data type for example
from the blob to the longblob if a temporary table is used.

The Item::make_string_field() function always converts Field_string objects 
to Field_varstring objects. This leads to changing data type from the 
char/binary to varchar/varbinary.

Added appropriate Field_timestamp object constructor for using in the 
Item::tmp_table_field_from_field_type() function.

Added Field_blob object constructor which sets pack length according to
max_length argument.

The Item::tmp_table_field_from_field_type() function now creates
Field_timestamp object for a timestamp field.

The Item_type_holder::display_length() now returns correct NULL length NULL
length. 

The Item::make_string_field() function now doesn't change Field_string to
Field_varstring in the case of Item_type_holder. 

The Item::tmp_table_field_from_field_type() function now uses the Field_blob
constructor which sets packlength according to max_length.

  This was only demonstrated by the use of PASSWORD(), it was not related to
  that function at all. The calculation of the size of a field in the results
  of a UNION did not take into account the possible growth of a string field
  when being converted to the aggregated character set.

resulted in a wrong error message.

The nest_level counter indicates the depth of nesting for a subselect. It is
needed to properly resolve aggregate functions in nested subselects. Obviously 
it shouldn't be incremented for UNION parts because they have the same level of
nesting. This counter was incremented by 1 in the mysql_new_select() function
for any new select and wasn't decremented for UNION parts. This resulted in
wrongly reported error messages.

Now the nest_level counter is decremented by 1 for any union part.

union.result, union.test:
  Adding test case.
item.cc:
  Allow safe character set conversion in UNION
  - string constant to column's charset
  - to unicode
  Thus, UNION now works the same with CONCAT (and other string functions)
  in respect of aggregating arguments with different character sets.

cause a crash or write to an incorrect memory location. (Bug #14216)

"Process NATURAL and USING joins according to SQL:2003".

* Some of the main problems fixed by the patch:
  - in "select *" queries the * expanded correctly according to
    ANSI for arbitrary natural/using joins
  - natural/using joins are correctly transformed into JOIN ... ON
    for any number/nesting of the joins.
  - column references are correctly resolved against natural joins
    of any nesting and combined with arbitrary other joins.

* This patch also contains a fix for name resolution of items
  inside the ON condition of JOIN ... ON - in this case items must
  be resolved only against the JOIN operands. To support such
  'local' name resolution, the patch introduces a stack of
  name resolution contexts used at parse time.

NOTICE:
- This patch is not complete in the sense that
  - there are 2 test cases that still do not pass -
    one in join.test, one in select.test. Both are marked
    with a comment "TODO: WL#2486".
  - it does not include a new test specific for the task

  Results for the above test case
union.test:
  A test case for bug #10032 involving UNION's and ORDER BY clause
sql_yacc.yy:
  Fix for a bug #10032 involving a parser bug with UNION's and ORDER BY

  fixing tests accordingly
item.cc:
  Allow mixing non-binary collation and binary collation
  even if coercibility is the same. 
  For easier 4.0 -> 4.1 migrating.

Fix that mysql.proc works with new VARCHAR fields
Give warnings for wrong zero dates

  Bug #6519 UNION with collation binary and latin1_swedish_ci fails now
  Prove that this problem was fixed with bug9425 fix too.

  Alter handling for UNION syntax
  Tests for UNION and parentheses

       bug#7833:  Wrong datatype of aggregate column is returned

not default_charset_into. It fixes the
problem that in some cases numbers where
treated as CHAR(N), not as BINARY(N), e.g.
wrong 'charsetnr' when sent to the client side.
2. IFNULL didn't aggregate argument charsets
and collations, so IFNULL(1,'a') produced
a CHAR(N). Now produces a BINARY(N).
3. SELECT PROCEDURE ANALIZE now returns
BINARY columns, which is much better than it worked
previously: CHAR with the default character set.
But in the future it's worth to fix the fields
'Field_name' and 'Optimal_fieldtype' to use UTF8,
and 'Min_value' and 'Max_value' to inherit their charsets
from the original items. But it is not important,
and BINARY(N) is OK for now.
4. Tests were fixed accordingly. No new tests were
made, as the old onces cover everything.

  added syntax:
  'show variables where', 'show status where', 'show open tables where'

- CREATE TABLE t1 SELECT BINARY 'literal'
  now creates a VARBINARY() column, not a BINARY().

Fixed compiler warnings
String results in CREATE ... SELECT are now created as CHAR(0), VARCHAR(X) or TEXT() depending on item->max_length

clause resolves collation conflict for the
first and the second parts pair.

Do not try use fields examples is expression and fiend used or SET/ENUM field used in types merging procedure (BUG#5618)