This bug in the constructor SEL_IMERGE::SEL_IMERGE could 
cause huge excessive memory requests.

- Take into account that there may exist Item_field objects with context==NULL.

BUG#952372: Server crashes on 2nd execution of PS in find_field_in_tables with semijoin+materialization
- The problem was that convert_subq_to_jtbm() attached the semi-join
  TABLE_LIST object into the wrong list: they used to attach it to the 
  end of parent_lex->leaf_tables.head()->next_local->...->next_local.
  This was apparently inccorect, as one can construct an example where 
  JTBM nest is attached to a table that is inside some mergeable VIEW, which
  breaks (causes crash) for name resolution on the subsequent statement
  re-execution.
- Solution: Attach to the "right" list. The "wording" was copied from
  st_select_lex::handle_derived.

Do not call, directly or indirectly, SQL_SELECT::test_quick_select()
for derived materialized tables / views when optimizing joins referring
to these tables / views to get cost estimates of materialization.
The current code does not create B-tree indexes for materialized 
derived tables / views. So now it's not possible to get any estimates
for ranges conditions over the results of the materialization.

The function mysql_derived_create() must take into account the fact
that array of the KEY structures specifying the keys over a derived
table / view may be moved after the optimization phase if the
derived table / view  is materialized.

Added 'from_end' as extra parameter to Field::unpack() to detect wrong from data.
Change ha_archive::unpack_row() to detect wrong field lengths.
Replication code changed to detect wrong field information in events.


mysql-test/r/archive.result:
  dded test case for lp:917689
sql/field.cc:
  Added 'from_end' as extra parameter to Field::unpack() to detect wrong from data.
  Removed not used 'unpack_key' functions.
sql/field.h:
  Added 'from_end' as extra parameter to Field::unpack() to detect wrong from data.
  Removed not used 'unpack_key' functions.
  Removed some not needed unpack() functions.
sql/filesort.cc:
  Added buffer end parameter to unpack_addon_fields()
sql/log_event.h:
  Added end of buffer argument to unpack_row()
sql/log_event_old.cc:
  Added end of buffer argument to unpack_row()
sql/log_event_old.h:
  Added end of buffer argument to unpack_row()
sql/records.cc:
  Added buffer end parameter to unpack_addon_fields()
sql/rpl_record.cc:
  Added end of buffer argument to unpack_row()
  Added detection of wrong field information in events
sql/rpl_record.h:
  Added end of buffer argument to unpack_row()
sql/rpl_record_old.cc:
  Added end of buffer argument to unpack_row()
  Added detection of wrong field information in events
sql/rpl_record_old.h:
  Added end of buffer argument to unpack_row()
sql/table.h:
  Added buffer end parameter to unpack()
storage/archive/ha_archive.cc:
  Change ha_archive::unpack_row() to detect wrong field lengths.
  This fixes lp:917689

- The bug would show up 
   - when using PS (so that we get re-execution)
   - the left_expr of the subquery is a reference to viewname.column_name, so that it crashes
      when one tries to use it without having called fix_fields for it.
   - when using SJ-Materialization, which makes use of sj_subq_pred->left_expr expression

- The fix is to have setup_conds() fix sj_subq_pred->left_expr for semi-join nests it finds.

This bug was introduced into mariadb 5.2 in the December 2010 with
the patch that added a new engine property: the ability to support
virtual columns.    
As a result of this bug the information from frm files for tables 
that contained virtual columns did not appear in the information schema
tables.

Added test case for lp:905782 "Assertion `pageno < ((1ULL) << 40)' failed at ma_pagecache.c:3438: pagecache_read or table corruption on INSERT into a ucs2 table"
The orignal bug has been fixed earlier

If in the where clause of the a query some comparison conditions on the
field under a MIN/MAX aggregate function contained constants whose sizes
exceeded the size of the field then the query could return a wrong result
when the optimizer had chosen to apply the MIN/MAX optimization.
With such conditions the MIN/MAX optimization still could be applied, yet
it would require a more thorough analysis of the keys built to find
the value of MIN/MAX aggregate functions with index look-ups.   
The current patch just prohibits using the MIN/MAX optimization in this
situation.

The function create_hj_key_for_table() that builds the descriptor of
the hash join key to access a table of a materialized subquery must
ignore any equi-join predicate depending on the tables not belonging
to the subquery.

Fixed detection of installed HeidiSQL in the machine, prevent installing own copy if HeidiSQL is already installed.

On deinstallation, do not remove settings if official HeidiSQL is detected.

This is needed as last log entry may be a DDL that is not processed and then a table may be left in 'not properly closed state' even if information is correct in it.

Problem is that subquery execution can't be called during prepare/optimize phase.

Also small fix for subquery test suite.

This bug in the function JOIN::drop_unused_derived_keys() could
leave the internal structures for a materialized derived table
in an inconsistent state. This led to a not quite correct EXPLAIN
output when no additional key had been created to access the table.
It also may lead to more serious consequences: so, the test case
added with this fix caused a crash in mariadb-5.5.20.  

This bug appeared after the patch for bug 939009 that in the
function merge_key_fields forgot to reset a proper value for
the val field in the result of the merge operation of the key
field created for a regular key access and  the key field
created to look for a NULL key.

Adjusted the results of the test case for bug 939009 that
actually were incorrect. 

Move ucs2 test in separate file (MDEV-167).

Fixed lp:925377 "Querying myisam table metadata while 'alter table..enable keys' is running may corrupt the table"
Fixed wrong mutex order bug in Aria when flush_log_for_bitmap() was called when table is not yet marked for change.

include/my_base.h:
  Added flag that table is opened only for status
mysql-test/r/myisam-big.result:
  Test case for lp:925377
mysql-test/t/myisam-big.test:
  Test case for lp:925377
sql/sql_base.cc:
  If thd->version == 0 (happens only when we are opening a table that is flushed under  MYSQL_LOCK_IGNORE_FLUSH), open the table in HA_OPEN_FOR_STATUS mode
storage/maria/ma_bitmap.c:
  Fixed wrong mutex order bug in Aria when flush_log_for_bitmap() was called when table is not yet marked for change.
storage/maria/ma_dbug.c:
  Ignore last_version <= 1 as these are either flushed or only opened for status
storage/maria/ma_open.c:
  Use last_version=1 as a marker that table was opened with HA_OPEN_FOR_STATUS.
  In this case we just open a new version of the table in read only mode.
storage/myisam/mi_create.c:
  Update prototype
storage/myisam/mi_dbug.c:
  Ignore last_version <= 1 as these are either flushed or only opened for status
storage/myisam/mi_open.c:
  Use last_version=1 as a marker that table was opened with HA_OPEN_FOR_STATUS.
  If HA_OPEN_FOR_STATUS is used, we will not assert if there is an old not-to-be-used version of the table existing.
  In this case we just open a new version of the table in read only mode.
storage/myisam/myisamdef.h:
  Updated prototype

make sure that stored routines are evaluated (that is, de facto - cached) in convert_const_to_int().
revert the fix for lp:806943 because it cannot be repeated anymore.
add few tests for convert_const_to_int()

The issue was that Aria allowed too long keys to be created (so that the internal buffer was not big enough to hold the whole key).
Key lengths is now limited to HA_MAX_KEY_LENGTH (1000), as for MyISAM.
Fixed failure in  "_ma_apply_redo_index: Assertion `new_page_length == 0", as found by buildbot.

mysql-test/suite/maria/r/maria.result:
  Updated results
mysql-test/suite/maria/r/maria3.result:
  Updated results. Added test for bug fix
mysql-test/suite/maria/t/maria3.test:
  Updated results. Added test for bug fix
mysql-test/suite/maria/t/optimize.test:
  Updated test for new max key length
storage/maria/ha_maria.cc:
  Limit key to HA_MAX_KEY_LENGTH.
storage/maria/ma_key_recover.c:
  Limit used page length to max page size (this is in line with the code that writes the entry to the log).
  This fixes failure in  "_ma_apply_redo_index: Assertion `new_page_length == 0", as found by buildbot.
storage/maria/ma_search.c:
  Extra DBUG
storage/maria/ma_write.c:
  Added test to detect errors earlier.

A better fix for this bug will be pulled from mariadb-5.2.

The field key_cache_mem_size of the KEY_CACHE structure must be
initialized in the function init_key_cache() and updated in the
function resize_key_cache().