After merge fix for bug#18739

into mysql.com:/M50/mysql-5.0

into  polar.kitebird.com:/src/extern/MySQL/bk/mysql-5.0

into  polar.kitebird.com:/src/extern/MySQL/bk/mysql-5.0

  myisam_ftdump options: --help first, then rest in
  lexical order.

into  mysql.com:/usr_rh9/home/elkin.rh9/MySQL/Merge/5.0

into  mysql.com:/usr_rh9/home/elkin.rh9/MySQL/Merge/5.0

The fix refines the algorithm of generating DROPs for binlog. 
Temp tables with common pseudo_thread_id are clustered into one query. 
Consequently one replication event per pseudo_thread_id is generated.

accounting non-ai32 in tmpkeyval. This changeset is supposed to be specifically for 4.1.
Another changeset is going to push into 5. 

into  mysql.com:/usr_rh9/home/elkin.rh9/MySQL/Merge/5.0

into  mysql.com:/usr_rh9/home/elkin.rh9/MySQL/Merge/5.0

into  mysql.com:/opt/local/work/mysql-5.0-runtime-merge

into  mysql.com:/home/alexi/innodb/mysql-5.0

  Backporting a changeset made for 5.0. Comments from there:

  The fix refines the algorithm of generating DROPs for binlog.
  Temp tables with common pseudo_thread_id are clustered into one query.
  Consequently one replication event per pseudo_thread_id is generated.

into  mysql.com:/home/alexi/innodb/mysql-4.1

into  mysql.com:/home/dlenev/mysql-5.0-bg15153-2

Error was emitted when one tried to select information from view which used
merge algorithm and which also had CONVERT_TZ() function in its select list.

This bug was caused by wrong assumption that global table list for view
which is handled using merge algorithm begins from tables belonging to
the main select of this view. Nowadays the above assumption is not true only
when one uses convert_tz() function in view's select list, but in future
other cases may be added (for example we may support merging of views
with subqueries in select list one day). Relying on this false assumption
led to the usage of wrong table list for field lookups and therefor errors. 

With this fix we explicitly use pointer to the beginning of main select's
table list.

into mysql.com:/M50/mysql-5.0

  Make InnoDB option "loose", as the server might be
  started with this option just to find out the test
  is to be skipped in the configuration (bug#17359)

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

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

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

Do not reset value of LAST_INSERT_ID() in sub-statement.

into mysql.com:/M50/mysql-5.0

Fixed windows compile error in sql/sp.cc (missing cast to byte*)

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

into  production.mysql.com:/usersnfs/rkalimullin/4.1.b18643

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

into  mysql.com:/extern/mysql/5.0/bug18344/mysql-5.0-runtime

into  neptunus.(none):/home/msvensson/mysql/my50-bug19190

into  rurik.mysql.com:/home/igor/dev/mysql-5.0-0

into  rurik.mysql.com:/home/igor/dev/mysql-4.1-0

The bug caused wrong result sets for union constructs of the form
(SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2.
For such queries order lists were concatenated and limit clause was
completely neglected. 

The SQL standard doesn't allow to use in HAVING clause fields that are not 
present in GROUP BY clause and not under any aggregate function in the HAVING
clause. However, mysql allows using such fields. This extension assume that 
the non-grouping fields will have the same group-wise values. Otherwise, the 
result will be unpredictable. This extension allowed in strict 
MODE_ONLY_FULL_GROUP_BY sql mode results in misunderstanding of HAVING 
capabilities.

The new error message ER_NON_GROUPING_FIELD_USED message is added. It says
"non-grouping field '%-.64s' is used in %-.64s clause". This message is
supposed to be used for reporting errors when some field is not found in the
GROUP BY clause but have to be present there. Use cases for this message are 
this bug and when a field is present in a SELECT item list not under any 
aggregate function and there is GROUP BY clause present which doesn't mention 
that field. It renders the ER_WRONG_FIELD_WITH_GROUP error message obsolete as
being more descriptive.
The resolve_ref_in_select_and_group() function now reports the 
ER_NON_GROUPING_FIELD_FOUND error if the strict mode is set and the field for 
HAVING clause is found in the SELECT item list only.