Null-merging revision
'revid: kevin.lewis@oracle.com-20101102151655-b9oe4ii46szw7vx1'
(Bug_57904 - Only one INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS was displayed
per table from Innodb) from mysql-5.5.7-rc-release.

The patch is already in mysql-5.5.8-release
(revid: kevin.lewis@oracle.com-20101102150314-a3jx98sg7wm3emge).

- Mark main.gis experimental

Reverting the patch.

Post-fix:
  Reverting the "utf16_bin did not sort supplementary characters
  between U+D700 and U+E000" part. We'll use code-point order.

Committing on behalf of Alexander Barkov.

Fix formatting issues in README file.

EXCEPTIONS-CLIENT from all the places.

If mysqltest dies, mtr waits to see if mysqld dies too within 100ms
But in that case, it should not care about expected crash
Fix: jump past the code that checks the expect file

While here, support supplying a '-j' flag to make(1) from
the environment.

Done as suggested
Also tested from src build directory

See bug #58416.

In case of low memory sort buffer QUICK_INDEX_MERGE_SELECT creates
temporary file where is stores row ids which meet QUICK_SELECT ranges
except of clustered pk range, clustered range is processed separately.
In init_read_record we check if temporary file is used and choose
appropriate record access method. It does not take into account that
temporary file contains partial result in case of QUICK_INDEX_MERGE_SELECT
with clustered pk range.
The fix is always to use rr_quick if QUICK_INDEX_MERGE_SELECT
with clustered pk range is used.

5.0-security --> 5.1-security

> revision-id: alexey.kopytov@sun.com-20100824103548-ikm79qlfrvggyj9h
> parent: sunny.bains@oracle.com-20100816001222-xqc447tr6jwh8c53
> committer: Alexey Kopytov <Alexey.Kopytov@Sun.com>
> branch nick: 5.1-security
> timestamp: Tue 2010-08-24 14:35:48 +0400
> message:
>   Bug #55568: user variable assignments crash server when used
>               within query
>   
>   The server could crash after materializing a derived table
>   which requires a temporary table for grouping.
>   
>   When destroying the temporary table used to execute a query for
>   a derived table, JOIN::destroy() did not clean up Item_fields
>   pointing to fields in the temporary table. This led to
>   dereferencing a dangling pointer when printing out the items
>   tree later in the outer SELECT.
>   
>   The solution is an addendum to the patch for bug37362: in
>   addition to cleaning up items in tmp_all_fields3, do the same
>   for items in tmp_all_fields1, since now we have an example
>   where this is necessary.