Re-execution of a parametrized prepared statement or a stored routine
with a SELECT that use LEFT JOIN with second table having only one row
could yield incorrect result.

The problem appeared only for left joins with second table having only
one row (aka const table) and equation conditions in ON or WHERE clauses
that depend on the argument passed.  Once the condition was false for
second const table, a NULL row was created for it, and any field involved
got NULL-value flag, which then was never reset.

The cause of the problem was that Item_field::null_value could be set
without being reset for re-execution.  The solution is to reset
Item_field::null_value in Item_field::cleanup().

into  bodhi.local:/opt/local/work/mysql-5.0-14897

into  bodhi.local:/opt/local/work/mysql-5.0-14897

into  mysql.com:/Users/kent/mysql/bk/mysql-5.0

into  mysql.com:/Users/kent/mysql/bk/mysql-5.0

  Auto merged

into  mysql.com:/Users/kent/mysql/bk/mysql-5.0

length limit", it's superseded by the fix for Bug#16899 "Possible buffer
overflow in handling of DEFINER-clause". Update test results.

into  bodhi.local:/opt/local/work/mysql-5.0-14897

doesn't find the column"

When a user was using 4.1 tables with VARCHAR column and 5.0 server
and a query that used a temporary table to resolve itself, the
table metadata for the varchar column sent to client was incorrect:
MYSQL_FIELD::table member was empty.

The bug was caused by implicit "upgrade" from old VARCHAR to new
VARCHAR hard-coded in Field::new_field, which did not preserve
the information about the original table. Thus, the field metadata
of the "upgraded" field pointed to an auxiliary temporary table
created for query execution.

The fix is to copy the pointer to the original table to the new field.

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

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug17591

  - BUG#15934: Instance manager fails to work;
  - BUG#18020: IM connect problem;
  - BUG#18027: IM: Server_ID differs;
  - BUG#18033: IM: Server_ID not reported;
  - BUG#21331: Instance Manager: Connect problems in tests;

The only test suite has been changed
(server codebase has not been modified).

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug17591

When a view was used inside a trigger or a function, lock type for
tables used in a view was always set to READ (thus making the view
non-updatable), even if we were trying to update the view.

The solution is to set lock type properly.

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

into  dl145s.mysql.com:/data/tkatchaounov/autopush/5.0-bug-21456

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

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

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

into  example.com:/work/mysql-5.0-runtime

into  zippy.cornsilk.net:/home/cmiller/work/mysql/release/mysql-5.0-release

	InterfaceError on connect

Removed the bool flag from the st_mysql_options struct, since it adds 
another word in size to the memory size and shifts member memory locations
down, both of which break binary-interface compatibility.

Instead, use a flag, 2**30, in the client_options bit-field to represent
that the client should check the SSL certificate of the server.

erroneous check

Problem: Actually there were two problems in the server code. The check
for SQLCOM_FLUSH in SF/Triggers were not according to the existing
architecture which uses sp_get_flags_for_command() from sp_head.cc .
This function was also missing a check for SQLCOM_FLUSH which has a
problem combined with prelocking. This changeset fixes both of these
deficiencies as well as the erroneous check in
sp_head::is_not_allowed_in_function() which was a copy&paste error.

into  mysql.com:/home/psergey/mysql-5.0-bug16255-merge

into  alik.:/mnt/raid/alik/MySQL/devel/5.0-rt-bug16899

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

const tables. This resulted in choosing extremely inefficient
execution plans in same cases when distribution of data in
joined were skewed (see the customer test case for the bug).

  Corrected fix for bug#18165

  Corrected fix for bug#18165

The following procedure was not possible if max_sp_recursion_depth is 0
create procedure show_proc() show create procedure show_proc;
  
Actually there is no recursive call but the limit is checked.
  
Solved by temporarily increasing the thread's limit just before the fetch from cache
and decreasing after that.

 Must not use Item_direct_ref in HAVING because it points to
 the new value (witch is not yet calculated for the first row).

Changed trigger-handling code so that there will be the one
place for generate statement string for replication log
and for trigger file.

    
User name (host name) has limit on length. The server code relies on these
limits when storing the names. The problem was that sometimes these limits
were not checked properly, so that could lead to buffer overflow.
  
The fix is to check length of user/host name in parser and if string is too
long, throw an error.

Changes in an item tree done by optimizer weren't properly
registered and went unnoticed, which resulted in preliminary freeing
of used memory.

  Corrected test case for the bug#21261
sql_parse.cc:
  Corrected fix for bug#21261