into  naruto.:C:/cpp/bug20777/my51-bug20777

- Stored procedures returning unsinged values returns signed values if
  text protocol is used. The reason is that the stored proceedure item
  Item_func_sp wasn't initializing the member variables properly based
  on the information contained in the associated result field.
- The patch is to upon field-item association, ::fix_fields, initialize
  the member variables in appropriate order.
- Field type of an Item_func_sp was hard coded to MYSQL_TYPE_VARCHAR.
  This is changed to return the type of the actual result field.
- Member function name sp_result_field was refactored to the more 
  appropriate init_result_field.
- Member function name find_and_check_access was refactored to 
  sp_check_access.

im_daemon_life_cycle fails randomly.

1. Move IM-angel functionality into a separate file, create Angel class.
2. Be more verbose;
3. Fix typo in FLUSH INSTANCES implementation;
4. Polishing.

into  weblab.(none):/home/marcsql/TREE/mysql-5.1-rt-merge

into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.1-maint

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

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

into  bk-internal.mysql.com:/data0/bk/mysql-5.1-opt

into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.1-maint

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

into  zippy.cornsilk.net:/home/cmiller/work/mysql/bug25807/my51-bug25807

Showstopper and regression against 5.0.24.

Previously, we ignored seek() errors (see Bug#22828) and let seek()s
against pipes fail.  Now, since we check that a seek didn't fail,
and return without reading, this bug popped up.

This restores the behavior for file-ish objects that could never be 
seek()ed.

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

into  zippy.cornsilk.net:/home/cmiller/work/mysql/tmpmerge

  Rename: BitKeeper/deleted/.del-README.txt -> BitKeeper/deleted/.del-README.txt-renamed

into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.1-maint

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

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

into  pilot.mysql.com:/home/msvensson/mysql/mysql-5.1-new-maint

into  pilot.mysql.com:/home/msvensson/mysql/mysql-5.1-new-maint

into  pilot.mysql.com:/home/msvensson/mysql/mysql-5.0-maint

into  pilot.mysql.com:/home/msvensson/mysql/mysql-5.0-maint

into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug26209

into  bk-internal.mysql.com:/data0/bk/mysql-5.1-opt

into  mysql.com:/home/kent/bk/tmp3/mysql-5.1

into  mysql.com:/home/hf/work/25492/my51-25492

into  mysql.com:/home/hf/work/25492/my50-25492

into  mysql.com:/home/hf/work/20691/my51-20691

into  mysql.com:/home/hf/work/25492/my50-25492

into  mysql.com:/home/hf/work/25492/my51-25492

into  weblab.(none):/home/marcsql/TREE/mysql-5.1-24532-merge

into  mysql.com:/home/hf/work/25492/my51-25492

into  mysql.com:/home/hf/work/25492/my50-25492

  operations)

Before this change, the boolean predicates:
- X IS TRUE,
- X IS NOT TRUE,
- X IS FALSE,
- X IS NOT FALSE
were implemented by expanding the Item tree in the parser, by using a
construct like:
Item_func_if(Item_func_ifnull(X, <value>), <value>, <value>)

Each <value> was a constant integer, either 0 or 1.

A bug in the implementation of the function IF(a, b, c), in
Item_func_if::fix_length_and_dec(), would cause the following :

When the arguments b and c are both unsigned, the result type of the
function was signed, instead of unsigned.

When the result of the if function is signed, space for the sign could be
counted twice (in the max() expression for a signed argument, and in the
total), causing the member max_length to be too high.

An effect of this is that the final type of IF(x, int(1), int(1)) would be
int(2) instead of int(1).

With this fix, the problems found in Item_func_if::fix_length_and_dec()
have been fixed.

While it's semantically correct to represent 'X IS TRUE' with
Item_func_if(Item_func_ifnull(X, <value>), <value>, <value>),
there are however more problems with this construct.

a)
Building the parse tree involves :
- creating 5 Item instances (3 ints, 1 ifnull, 1 if),
- creating each Item calls my_pthread_getspecific_ptr() once in the operator
  new(size), and a second time in the Item::Item() constructor, resulting
  in a total of 10 calls to get the current thread.
Evaluating the expression involves evaluating up to 4 nodes at runtime.
This representation could be greatly simplified and improved.

b)
Transforming the parse tree internally with if(ifnull(...)) is fine as long
as this transformation is internal to the server implementation.
With views however, the result of the parse tree is later exposed by the
::print() functions, and stored as part of the view definition.
Doing this has long term consequences:

1)
The original semantic 'X IS TRUE' is lost, and replaced by the
if(ifnull(...)) expression. As a result, SHOW CREATE VIEW does not restore
the original code.

2)
Should a future version of MySQL implement the SQL BOOLEAN data type for
example, views created today using 'X IS NULL' can be exported using
mysqldump, and imported again. Such views would be converted correctly and
automatically to use a BOOLEAN column in the future version.
With 'X IS TRUE' and the current implementations, views using these
"boolean" predicates would not be converted during the export/import, and
would use integer columns instead.
The difference traces back to how SHOW CREATE VIEW preserves 'X IS NULL' but
does not preserve the 'X IS TRUE' semantic.

With this fix, internal representation of 'X IS TRUE' booleans predicates
has changed, so that:
- dedicated Item classes are created for each predicate,
- only 1 Item is created to represent 1 predicate
- my_pthread_getspecific_ptr() is invoked 1 time instead of 10
- SHOW CREATE VIEW preserves the original semantic, and prints 'X IS TRUE'.

Note that, because of the fix in Item_func_if, views created before this fix
will:
- correctly use a int(1) type instead of int(2) for boolean predicates,
- incorrectly print the if(ifnull(...), ...) expression in SHOW CREATE VIEW,
since the original semantic (X IS TRUE) has been lost.
- except for the syntax used in SHOW CREATE VIEW, these views will operate
properly, no action is needed.

Views created after this fix will operate correctly, and will preserve the
original code semantic in SHOW CREATE VIEW.