The function generate_derived_keys did not take into account the fact
that the last element in the array of keyuses could be just a barrier
element. In some cases it could lead to a crash of the server.

Also fixed a couple of other bugs in generate_derived_keys: the inner 
loop in the body of if this function did not change the cycle variables
properly.

INSERT/UPDATE/DELETE statement that used a temptable view v1 could lead to
a crash if v1 was defined as a select from a mergeable view v2 that selected
rows from a temptable view v3. 
 
When INSERT/UPDATE/DELETE uses a view that is not updatable then field
translation for the view should be created before the prepare phase.

When looking for the execution plan of a derived table to be materialized
JOIN::optimize finds  out that all joined tables of the derived table
contain not more than one row then the derived table should be maretialized
at the optimization stage.
Added a test case for the bug.
Adjusted results in other test cases.

'derived_merge':
  - if the flag is off then all derived tables are materialized
  - if the flag is on then mergeable derived tables are merged
'derived_with_keys':
  - if the flag is off then no keys are created for derived tables
  - if the flag is on then for any derived table a key to access 
    the derived table may be created.

Now by default both flags are on.
Later the default values for the flags will be off to comply with
the current behaviour of mysql-5.1. 

Uncommented previously commented out test case from parts.partition_repair_myisam
after having added an explicit requirement to materialize the derived
table used in the test case.  

 

Resolved all conflicts and failures.

Uncommented the failing test cases.

Commented out the failing test case from parts.partition_repair_myisam.test.
The test case has to be changed to bear the same semantics as before mwl106.
 

- make sp.test work both with and without query_cache (attempt 2)
- fix compile warning in make_sort_key(), as directed by SergeiG

to be optimizer_switch flags mrr=on|off and mrr_cost_based=on|off.

- Don't attempt to construct FirstMatch access method if we've 
  just figured three lines above that it can't be used (because join
  prefix doesn't have the needed tables), and so have set 
    pos->first_firstmatch_table= MAX_TABLES 
  Attempts to analyze join->positions[MAX_TABLES] caused valgrind warnings

sql/sql_base.cc:
  Column for views should be looked in views (not in underlying table)
sql/sql_parse.cc:
  if we reread grants for single table we should read both database and tables grants for views (not only database grants).

Corrected the code from the patch for  LP bug 702322.

There is a potential race when we stop the slave. It may take some time for
the master to detect that the slave connection is closed (eg. if scheduling
delays the TCP RSET packet or whatever). Since we inject only a single corrupt
binlog event, we may be unfortunate enough to inject it on the wrong
connection, to a slave io thread that's already stopped.

Fix by waiting for the old dump thread on the master to go away before
injecting the corrupt event.

sql/sql_expression_cache.cc:
  The call should not open the temporary table. It will be done later after its index creation.

- Remove garbage comments

introduced at the latest merge 5.1->5.2->5.3.
It is basically not needed since if SQL_SELECT::pre_idx_push_select_cond 
is not NULL then SQL_SELECT::original_cond would point to the same condition
as SQL_SELECT::pre_idx_push_select_cond. Otherwise SQL_SELECT::original_cond
would be equal to SQL_SELECT::cond.

The fix blocks execution of any constant sub-expressions of
the defining expressions for virtual columns when context
analysis if these expressions is performed.

Fixed a compiler warning.

- Code cleanup: remove garbage comments

- Don't call table_list->process_index_hints() for JTBM pseudo-tables
- Update test results

- bad .result merge
- make .test file do not switch off both materialization and IN->EXISTS as that leads to error now.

- Update test results (checked)
- Fix compiler warning

way of processing prepared statements:
- conversion subquery_predicate -> TABLE_LIST is once per-statement
- However, the code must take into account that materialized temptable
  is dropped and re-created on each execution (the tricky part is that 
  at start of n-th EXECUTE we have TABLE_LIST object but not its TABLE object)
- IN-equality is injected into WHERE on every execution.

Also, change windows timespec definition to be Unix-ish - simplifies handling a lot.