- The bug was caused by outer join being incorrectly converted into inner because of 
  invalid return values of Item_direct_view_ref::not_null_tables().
- Provided a correct Item_direct_view_ref::not_null_tables() function.

The method Item_ref::not_null_tables() returned incorrect bitmap
for outer references to view columns. This could cause an invalid
conversion of an outer join into an inner join that could lead
to a wrong result set for a query with a correlated subquery over
an outer join whose where condition had an outer reference to a view.

off by default.

In case of two views with subqueries it is dificult to decide about order of injected ORDER BY clauses.
A simple solution is just prohibit ORDER BY injection if there is other order by.

mysql-test/r/view.result:
  New test added, old test changed.
mysql-test/t/view.test:
  New test aded.
sql/share/errmsg.txt:
  new warning added.
sql/sql_view.cc:
  Inject ORDER BY only if there is no other one.
  
  Warning about ignoring ORDER BY in this case for EXPLAIN EXTENDED.

Fixed explains of previous patch.

mysql-test/r/explain.result:
  Fixed explains of previous patch.
mysql-test/r/join_outer.result:
  Fixed explains of previous patch.
mysql-test/r/negation_elimination.result:
  Fixed explains of previous patch.
mysql-test/r/view.result:
  Fixed explains of previous patch.
mysql-test/suite/innodb/r/innodb_mysql.result:
  Removed duplicate test suite.
mysql-test/suite/innodb/t/innodb_mysql.test:
  Removed duplicate test suite.
mysql-test/suite/innodb_plugin/r/innodb_mysql.result:
  Removed duplicate test suite.
mysql-test/suite/innodb_plugin/t/innodb_mysql.test:
  Removed duplicate test suite.
sql/opt_range.h:
  Removed incorrect fix.
sql/records.cc:
  Removed incorrect fix.

There are 2 volatile condition constructions AND/OR constructions and fields(references) when first
good supported to be top elements of conditions because it is normal practice
(see copy_andor_structure for example) fields without any expression in the condition is really rare
and mostly useless case however it could lead to problems when optimiser changes/moves them unaware
of other variables referring to them. An easy solution of this problem is just to replace single field
in a condition with equivalent expression well supported by the server (<field> -> <field> != 0).

mysql-test/r/view.result:
  New test added.
mysql-test/t/view.test:
  New test added.
sql/sql_parse.cc:
  <field> -> <field> != 0
sql/sql_yacc.yy:
  <field> -> <field> != 0

Auto-generated names for view field items must be allocated in
the statement memory, not in the execution memory of the statement.

- Set the default
- Adjust the testcases so that 'new' tests are run with optimizations turned on.
- Pull out relevant tests from "irrelevant" tests and run them with optimizations on.
- Run range.test and innodb.test with both mrr=on and mrr=off

The assert conditions in the functions Item_direct_ref_to_ident::transform
and Item_direct_ref_to_ident::compile could be not valid after constant
propagation when fields and field references may be substituted for constants.
Not only these invalid asserts have been removed, but the functions containing
them have been removed as well because now Item_ref::transform and 
Item_ref::compile can be used instead of them.

- JOIN::prepare would have set JOIN::table_count to incorrect value (bad merge of MWL 106)
- optimize_keyuse() would use table-bit as table number
  (the change in optimize_keyuse is also the reason for query plan changes. Not 
   expected to have much effect because only handles cases of no index statistics)
- st_select_lex::register_dependency_item() ignored the fact that some of the 
  selects on the dependency paths could have been merged to their parents (because they 
  were mergeable VIEWs)
- Undo the incorrect fix in Item_subselect::recalc_used_tables(): do not call 
  fix_after_pullout() for Item_subselect::Ref_to_outside members. 

fixed by the patch for LP bug 798621.

If a view/derived table is non-mergeable then the definition of the tmp table
to store the rows for it is created at the prepare stage. In this case if the
view definition uses outer joins and a view column belongs to an inner table
of one of them then the column should be considered as nullable independently
on nullability of the underlying column. If the underlying column happens to be
defined as non-nullable then the function create_tmp_field_from_item rather 
than the function create_tmp_field_from_field should be employed to create
the definition of the interesting column in the tmp table.
 

The patch for bugs 717577 and 724942 has missed to make adjustments for the
call item_equal->add_const(const_item, orig_field_item) in the function
check_simple_equality that builds multiple equality for a field and a constant.
As a result, when this field happens to be a view field and the corresponding
Item_field object F is wrapped in an Item_direct_view_ref object R the object
F is placed in the multiple equality instead of the object R.
A substitution of an equal item for F potentially can cause very serious
problems and in some cases can lead to crashes of the server.

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.

Fields belonging to views in general cannot be substituted for 
equal items, in particular for constants, because all references
to a view field refer to the same Item_field object while they 
could be used in different OR parts of the where condition and
belong to different equivalence classes (to different Item_equals).
That's why substitution for equal items in any context is allowed
only in place of Item_direct_view_ref objects, but not in place of
Item_fields these objects refer to.
Due to some erroneous code in the patch for bug 717577 substitution
for view fields were allowed in some context.This could lead
to wrong results returned by queries using views.

The fix prohibits substitution of view fields for equal items 
in any context.

The patch also changes slightly the compile method for the Item_func
class. Now if the analyze method returns NULL in his parameter the
compile method is not called for the arguments of the function
at all. A similar change was made for the Item_ref class.     

When a view is merged into a select all the depended_from fields
pointing to the select of the view should have been corrected to
point to the select where the view is used. It was not done yet.
This could lead to wrong results returned by queries such as
one from the test case for bug 33389.
Correction of outer references required walking through all items
of the proccesed qurery. To avoid this the following solution was
implemented.
Each select now contains a pointer to the select it is merged into
(if there is any). Such pointers allow to get the corrected value
of depended_from on the fly. The function Item_ident::get_depended_from
was introduced for this purpose.

Both these two bugs happened due to the following problem.
When a view column is referenced in the query an Item_direct_view_ref
object is created that is refers to the Item_field for the column.
All references to the same view column refer to the same Item_field.
Different references can belong to different AND/OR levels and,
as a result, can be included in different Item_equal object.
These Item_equal objects may include different constant objects.
If these constant objects are substituted for the Item_field created
for a view column we have a conflict situation when the second
substitution annuls the first substitution. This leads to
wrong result sets returned by the query. Bug #724942 demonstrates
such an erroneous behaviour.
Test case of the bug #717577 produces wrong result sets because best
equal fields of the multiple equalities built for different OR levels
of the WHERE condition differs. The subsitution for the best equal field
in the second OR branch overwrites the the substitution made for the
first branch.

To avoid such conflicts we have to substitute for the references
to the view columns rather than for the underlying field items.
To make such substitutions possible we have to include into
multiple equalities references to view columns rather than 
field items created for such columns.

This patch modifies the Item_equal class to include references
to view columns into multiple equality objects. It also performs
a clean up of the class methods and adds more comments. The methods
of the Item_direct_view_ref class that assist substitutions for
references to view columns has been also added by this patch.

Select from a view with the underlying HAVING clause failed with a
message: "1356: View '...' references invalid table(s) or column(s)
or function(s) or definer/invoker of view lack rights to use them"

The bug is a regression of the fix for bug 11750328 - 40825 (similar
case, but the HAVING cause references an aliased field).
In the old fix for bug 40825 the Item_field::name_length value has
been used in place of the real length of Item_field::name. However,
in some cases Item_field::name_length is not in sync with the
actual name length (TODO: combine name and name_length into a
solid String field).

The Item_ref::print() method has been modified to calculate actual
name length every time.


mysql-test/r/view.result:
  Test case for bug #11829681
mysql-test/t/view.test:
  Test case for bug #11829681
sql/item.cc:
  Bug #11829681 - 60295: ERROR 1356 ON VIEW THAT EXECUTES FINE AS A QUERY
  
  The Item_ref::print() method has been modified to calculate actual
  name length every time.
sql/item.h:
  Minor commentary.

> ------------------------------------------------------------
> revno: 3520
> revision-id: sergey.glukhov@oracle.com-20101214093303-wmo9mqcb8rz0wv9f
> parent: tor.didriksen@oracle.com-20101213161301-81lprlbune7r98dl
> committer: Sergey Glukhov <sergey.glukhov@oracle.com>
> branch nick: mysql-5.1-bugteam
> timestamp: Tue 2010-12-14 12:33:03 +0300
> message:
>   Fixed following problems:
>   --Bug#52157 various crashes and assertions with multi-table update, stored function
>   --Bug#54475 improper error handling causes cascading crashing failures in innodb/ndb
>   --Bug#57703 create view cause Assertion failed: 0, file .\item_subselect.cc, line 846
>   --Bug#57352 valgrind warnings when creating view
>   --Recently discovered problem when a nested materialized derived table is used
>     before being populated and it leads to incorrect result
>   
>   We have several modes when we should disable subquery evaluation.
>   The reasons for disabling are different. It could be
>   uselessness of the evaluation as in case of 'CREATE VIEW'
>   or 'PREPARE stmt', or we should disable subquery evaluation
>   if tables are not locked yet as it happens in bug#54475, or
>   too early evaluation of subqueries can lead to wrong result
>   as it happened in Bug#19077.
>   Main problem is that if subquery items are treated as const
>   they are evaluated in ::fix_fields(), ::fix_length_and_dec()
>   of the parental items as a lot of these methods have
>   Item::val_...() calls inside.
>   We have to make subqueries non-const to prevent unnecessary
>   subquery evaluation. At the moment we have different methods
>   for this. Here is a list of these modes:
>   
>   1. PREPARE stmt;
>   We use UNCACHEABLE_PREPARE flag.
>   It is set during parsing in sql_parse.cc, mysql_new_select() for
>   each SELECT_LEX object and cleared at the end of PREPARE in
>   sql_prepare.cc, init_stmt_after_parse(). If this flag is set
>   subquery becomes non-const and evaluation does not happen.
>   
>   2. CREATE|ALTER VIEW, SHOW CREATE VIEW, I_S tables which
>      process FRM files
>   We use LEX::view_prepare_mode field. We set it before
>   view preparation and check this flag in
>   ::fix_fields(), ::fix_length_and_dec().
>   Some bugs are fixed using this approach,
>   some are not(Bug#57352, Bug#57703). The problem here is
>   that we have a lot of ::fix_fields(), ::fix_length_and_dec()
>   where we use Item::val_...() calls for const items.
>   
>   3. Derived tables with subquery = wrong result(Bug19077)
>   The reason of this bug is too early subquery evaluation.
>   It was fixed by adding Item::with_subselect field
>   The check of this field in appropriate places prevents
>   const item evaluation if the item have subquery.
>   The fix for Bug19077 fixes only the problem with
>   convert_constant_item() function and does not cover
>   other places(::fix_fields(), ::fix_length_and_dec() again)
>   where subqueries could be evaluated.
>   
>   Example:
>   CREATE TABLE t1 (i INT, j BIGINT);
>   INSERT INTO t1 VALUES (1, 2), (2, 2), (3, 2);
>   SELECT * FROM (SELECT MIN(i) FROM t1
>   WHERE j = SUBSTRING('12', (SELECT * FROM (SELECT MIN(j) FROM t1) t2))) t3;
>   DROP TABLE t1;
>   
>   4. Derived tables with subquery where subquery
>      is evaluated before table locking(Bug#54475, Bug#52157)
>   
>   Suggested solution is following:
>   
>   -Introduce new field LEX::context_analysis_only with the following
>    possible flags:
>    #define CONTEXT_ANALYSIS_ONLY_PREPARE 1
>    #define CONTEXT_ANALYSIS_ONLY_VIEW    2
>    #define CONTEXT_ANALYSIS_ONLY_DERIVED 4
>   -Set/clean these flags when we perform
>    context analysis operation
>   -Item_subselect::const_item() returns
>    result depending on LEX::context_analysis_only.
>    If context_analysis_only is set then we return
>    FALSE that means that subquery is non-const.
>    As all subquery types are wrapped by Item_subselect
>    it allow as to make subquery non-const when
>    it's necessary.

with the test case added by this patch.
The bug cannot be reproduced with the same test case for the main
5.3 tree because the backported fix for bug 59696 masks the 
problem that causes the crash in the mentioned test case. It's not
clear weather this fix masks this problem in all possible cases. 

Anyway the patch for bug 698882 introduced some inconsistent data
structures that could contain indirect references to deleted object.
It happened when two Item_equal objects were merged and the Item_field
list of the second object was joined to such list of the first object.
This operation required adjustment of the backward pointers in 
Item fields from the joined list. However the adjustment was missing 
and this caused crashes in the tree for mwl#128.

Now the backward pointers are set only when Item_equal items are
completely built and are not changed anymore.
 

The patch fixed the following optimizer defect: when performing
substitution for best equal fields into where conditions to be
able to do their evaluations as soon as possible the optimizer 
skipped conditions over views. That could lead to suboptimal 
execution of queries that used views.  
Slightly changed the test case to demonstrate the performance
improvements if this fix.

--Bug#52157 various crashes and assertions with multi-table update, stored function
--Bug#54475 improper error handling causes cascading crashing failures in innodb/ndb
--Bug#57703 create view cause Assertion failed: 0, file .\item_subselect.cc, line 846
--Bug#57352 valgrind warnings when creating view
--Recently discovered problem when a nested materialized derived table is used
  before being populated and it leads to incorrect result

We have several modes when we should disable subquery evaluation.
The reasons for disabling are different. It could be
uselessness of the evaluation as in case of 'CREATE VIEW'
or 'PREPARE stmt', or we should disable subquery evaluation
if tables are not locked yet as it happens in bug#54475, or
too early evaluation of subqueries can lead to wrong result
as it happened in Bug#19077.
Main problem is that if subquery items are treated as const
they are evaluated in ::fix_fields(), ::fix_length_and_dec()
of the parental items as a lot of these methods have
Item::val_...() calls inside.
We have to make subqueries non-const to prevent unnecessary
subquery evaluation. At the moment we have different methods
for this. Here is a list of these modes:

1. PREPARE stmt;
We use UNCACHEABLE_PREPARE flag.
It is set during parsing in sql_parse.cc, mysql_new_select() for
each SELECT_LEX object and cleared at the end of PREPARE in
sql_prepare.cc, init_stmt_after_parse(). If this flag is set
subquery becomes non-const and evaluation does not happen.

2. CREATE|ALTER VIEW, SHOW CREATE VIEW, I_S tables which
   process FRM files
We use LEX::view_prepare_mode field. We set it before
view preparation and check this flag in
::fix_fields(), ::fix_length_and_dec().
Some bugs are fixed using this approach,
some are not(Bug#57352, Bug#57703). The problem here is
that we have a lot of ::fix_fields(), ::fix_length_and_dec()
where we use Item::val_...() calls for const items.

3. Derived tables with subquery = wrong result(Bug19077)
The reason of this bug is too early subquery evaluation.
It was fixed by adding Item::with_subselect field
The check of this field in appropriate places prevents
const item evaluation if the item have subquery.
The fix for Bug19077 fixes only the problem with
convert_constant_item() function and does not cover
other places(::fix_fields(), ::fix_length_and_dec() again)
where subqueries could be evaluated.

Example:
CREATE TABLE t1 (i INT, j BIGINT);
INSERT INTO t1 VALUES (1, 2), (2, 2), (3, 2);
SELECT * FROM (SELECT MIN(i) FROM t1
WHERE j = SUBSTRING('12', (SELECT * FROM (SELECT MIN(j) FROM t1) t2))) t3;
DROP TABLE t1;

4. Derived tables with subquery where subquery
   is evaluated before table locking(Bug#54475, Bug#52157)

Suggested solution is following:

-Introduce new field LEX::context_analysis_only with the following
 possible flags:
 #define CONTEXT_ANALYSIS_ONLY_PREPARE 1
 #define CONTEXT_ANALYSIS_ONLY_VIEW    2
 #define CONTEXT_ANALYSIS_ONLY_DERIVED 4
-Set/clean these flags when we perform
 context analysis operation
-Item_subselect::const_item() returns
 result depending on LEX::context_analysis_only.
 If context_analysis_only is set then we return
 FALSE that means that subquery is non-const.
 As all subquery types are wrapped by Item_subselect
 it allow as to make subquery non-const when
 it's necessary.


mysql-test/r/derived.result:
  test case
mysql-test/r/multi_update.result:
  test case
mysql-test/r/view.result:
  test case
mysql-test/suite/innodb/r/innodb_multi_update.result:
  test case
mysql-test/suite/innodb/t/innodb_multi_update.test:
  test case
mysql-test/suite/innodb_plugin/r/innodb_multi_update.result:
  test case
mysql-test/suite/innodb_plugin/t/innodb_multi_update.test:
  test case
mysql-test/t/derived.test:
  test case
mysql-test/t/multi_update.test:
  test case
mysql-test/t/view.test:
  test case
sql/item.cc:
  --removed unnecessary code
sql/item_cmpfunc.cc:
  --removed unnecessary checks
  --THD::is_context_analysis_only() is replaced with LEX::is_ps_or_view_context_analysis()
sql/item_func.cc:
  --refactored context analysis checks
sql/item_row.cc:
  --removed unnecessary checks
sql/item_subselect.cc:
  --removed unnecessary code
  --added DBUG_ASSERT into Item_subselect::exec()
    which asserts that subquery execution can not happen
    if LEX::context_analysis_only is set, i.e. at context
    analysis stage.
  --Item_subselect::const_item()
    Return FALSE if LEX::context_analysis_only is set.
    It prevents subquery evaluation in ::fix_fields &
    ::fix_length_and_dec at context analysis stage.
sql/item_subselect.h:
  --removed unnecessary code
sql/mysql_priv.h:
  --Added new set of flags.
sql/sql_class.h:
  --removed unnecessary code
sql/sql_derived.cc:
  --added LEX::context_analysis_only analysis intialization/cleanup
sql/sql_lex.cc:
  --init LEX::context_analysis_only field
sql/sql_lex.h:
  --New LEX::context_analysis_only field
sql/sql_parse.cc:
  --removed unnecessary code
sql/sql_prepare.cc:
  --removed unnecessary code
  --added LEX::context_analysis_only analysis intialization/cleanup
sql/sql_select.cc:
  --refactored context analysis checks
sql/sql_show.cc:
  --added LEX::context_analysis_only analysis intialization/cleanup
sql/sql_view.cc:
  --added LEX::context_analysis_only analysis intialization/cleanup

Improved error handling such that queries against Information_Schema.Tables won't
fail if a Federated table is unable to connect to remote host.



sql/sql_show.cc:
  If Handler::Info() fails, save error text in TABLE COMMENTS column, clear error.

metadata"
            
Improved error handling such that queries against Information_Schema.Tables won't
fail if a federated table can't make a remote connection.

mysql-test/r/merge.result:
  Updated with warnings that were previously masked.
mysql-test/r/show_check.result:
  Updated with warnings that were previously masked.
mysql-test/r/view.result:
  Updated with warnings that were previously masked.
sql/sql_show.cc:
  If get_schema_tables_record() encounters an error, push a warning,
  set the TABLE COMMENT column with the error text, and clear the
  error so that the operation can continue.

about the employed join algorithms.
Refactored constructors of the JOIN_CACHE* classes.

Applied the fix for bug #47217 from the mysql-6.0 codebase.
The patch adds not null predicates generated for the left parts
of the equality predicates used for ref accesses. This is done
for such predicates both in where conditions and on conditions.
For the where conditions the not null predicates were generated
but in 5.0/5.1 they actually never were used due to some lame
merge from 4.1 to 5.0. The fix for bug #47217 made these 
predicates to be used in the condition pushed to the tables.
Yet only this patch generates not null predicates for equality
predicated from on conditions of outer joins.
This patch introduces a performance regression that can be
observed on a test case from null_key.test. The regression
will disappear after the fix for bug #57024 from mariadb-5.1
is pulled into mariadb-5.3.
The patch contains many changes in the outputs of the EXPLAIN 
commands since generated not null predicates are considered as
parts of the conditions pushed to join tables and may add
'Usingwhere' in some rows of EXPLAINs where there used
to be no such comments.

The problem could be demonstrated with an outer join of two single-row
tables where the values of the join attributes were null. Any query
with such a join could return a wrong result set if the where
condition of the query was not empty. For queries with empty
where conditions the result sets were correct.
This was the consequence of two bugs in the code:
 - Item_equal objects for on conditions of outer joins were
   not built if the processed query had no where condition
 - the check for null values in the code that evaluated constant 
   Item_equal objects was incorrect.
Fixed both above problems.
Added a test case for the bug and adjusted results for some other
test cases.

The main consolidated patch.

  non-semijoin materialized subqueries that are AND-parts of the WHERE
- Update test results.

We should disable const subselect item evaluation because
subselect transformation does not happen in view_prepare_mode
and thus val_...() methods can not be called.


mysql-test/r/ctype_ucs.result:
  test case
mysql-test/r/view.result:
  test case
mysql-test/t/ctype_ucs.test:
  test case
mysql-test/t/view.test:
  test case
sql/item.cc:
  disabled const subselect item evaluation in
  view prepare mode.
sql/item_subselect.cc:
  added Item_subselect::safe_charset_converter which
  prevents const item evaluation in view prepare mode.
sql/item_subselect.h:
  added Item_subselect::safe_charset_converter which
  prevents const item evaluation in view prepare mode.

The problem is that not all column names retrieved from a SELECT
statement can be used as view column names due to length and format
restrictions. The server failed to properly check the conformity
of those automatically generated column names before storing the
final view definition on disk.

Since columns retrieved from a SELECT statement can be anything
ranging from functions to constants values of any format and length,
the solution is to rewrite to a pre-defined format any names that
are not acceptable as a view column name.

The name is rewritten to "Name_exp_%u" where %u translates to the
position of the column. To avoid this conversion scheme, define
explict names for the view columns via the column_list clause.
Also, aliases are now only generated for top level statements.

mysql-test/include/view_alias.inc:
  Add test case for Bug#40277
mysql-test/r/compare.result:
  Bug#40277: SHOW CREATE VIEW returns invalid SQL
mysql-test/r/group_by.result:
  Bug#40277: SHOW CREATE VIEW returns invalid SQL
mysql-test/r/ps.result:
  Bug#40277: SHOW CREATE VIEW returns invalid SQL
mysql-test/r/subselect.result:
  Bug#40277: SHOW CREATE VIEW returns invalid SQL
mysql-test/r/subselect3.result:
  Bug#40277: SHOW CREATE VIEW returns invalid SQL
mysql-test/r/type_datetime.result:
  Bug#40277: SHOW CREATE VIEW returns invalid SQL
mysql-test/r/union.result:
  Bug#40277: SHOW CREATE VIEW returns invalid SQL
mysql-test/r/view.result:
  Add test case result for Bug#40277
mysql-test/r/view_alias.result:
  Add test case result for Bug#40277
mysql-test/t/view_alias.test:
  Add test case for Bug#40277
sql/sql_view.cc:
  Check if auto generated column names are conforming. Also, the
  make_unique_view_field_name function is not used as it uses the
  original name to construct a new one, which does not work if the
  name is invalid.

- More test results updates (checked)

When one does a drop table, the indexes are not flushed to disk before drop anymore (with MyISAM/Maria)
myisam-recover options changed from OFF to 'DEFAULT' to get less change of data loss when using MyISAM.
(The disadvantage is that changed MyISAM tables will be checked at access time; Use --myisam-recover=OFF for old behavior)
Don't call extra(HA_EXTRA_FORCE_REOPEN) in ALTER TABLE if table is locked as this will mark table as crashed!
Added assert to detect if we accidently would use MyISAM versioning in MySQL

include/my_base.h:
  Mark NOT_USED as USED, as we now use this as a flag to not call extra()
mysql-test/mysql-test-run.pl:
  Don't write all options when there is something wrong with the arguments
mysql-test/r/sp-destruct.result:
  Add missing flush of mysql.proc (as the test copied live tables)
mysql-test/r/variables.result:
  myisam-recover options changed to 'default'
mysql-test/r/view.result:
  Don't show create time in result
mysql-test/suite/maria/t/maria-recovery2-master.opt:
  Don't run test with myisam-recover (as this produces extra warnings during simulated death)
mysql-test/t/sp-destruct.test:
  Add missing flush of mysql.proc (as the test copied live tables)
mysql-test/t/view.test:
  Don't show create time in result
sql/lock.cc:
  Added marker if table was deleted to argument list
sql/mysql_priv.h:
  Added marker if table was deleted to argument list
sql/mysqld.cc:
  myisam-recover options changed from OFF to 'DEFAULT' to get less change of data loss when using MyISAM
  Allow one to specify OFF as argument to myisam-recover (was default before but one couldn't specify it)
sql/sql_base.cc:
  Mark if table is going to be deleted
sql/sql_delete.cc:
  Mark if table is going to be deleted
sql/sql_table.cc:
  Mark if table is going to be deleted
  Don't call extra(HA_EXTRA_FORCE_REOPEN) in ALTER TABLE if table is locked as this will mark table as crashed!
sql/table.cc:
  Signal to handler if table is getting deleted as part of getting droped from table cache.
sql/table.h:
  Added marker if table is going to be deleted.
storage/maria/ha_maria.cc:
  Don't search for transaction handler if file is not transactional or outside of transaction
  (Fixed possible core dump)
storage/maria/ma_blockrec.c:
  Don't write changed information if table is going to be deleted.
storage/maria/ma_close.c:
  Don't write changed information if table is going to be deleted.
storage/maria/ma_extra.c:
  Mark tables that are deleted as crased, to ensure good behavior on restart if we suddenly crash.
storage/maria/ma_locking.c:
  Cleanup
storage/maria/ma_recovery.c:
  We need trnman to be inited during redo phase (to be able to open tables checked with maria_chk)
storage/maria/maria_def.h:
  Added marker if table is going to be deleted.
storage/myisam/mi_close.c:
  Don't write changed information if table is going to be deleted.
storage/myisam/mi_extra.c:
  Mark tables that are deleted as crased, to ensure good behavior on restart if we suddenly crash.
storage/myisam/mi_open.c:
  Added assert to detect if we accidently would use MyISAM versioning in MySQL
storage/myisam/myisamdef.h:
  Added marker if table is going to be deleted.

In case of 'CREATE VIEW' subselect transformation does not happen(see JOIN::prepare).
During fix_fields Item_row may call is_null() method for its arugmens which
leads to item calculation(wrong subselect in our case as
transformation did not happen before). This is_null() call
does not make sence for 'CREATE VIEW'.
Note:
Only Item_row is affected because other items don't call is_null() 
during fix_fields() for arguments.

mysql-test/r/view.result:
  test case
mysql-test/t/view.test:
  test case
sql/item_row.cc:
  skip is_null() call in case of 'CREATE VIEW' as unnecessary.

related bits.

SHOW CREATE TABLE on a view (v1) that contains a function whose
statement uses another view (v2), could trigger a infinite loop
if the view referenced within the function causes a warning to
be raised while opening the said view (v2).

The problem was a infinite loop over the stack of internal error
handlers. The problem would be triggered if the stack contained
two or more handlers and the first two handlers didn't handle the
raised condition. In this case, the loop variable would always
point to the second handler in the stack.

The solution is to correct the loop variable assignment so that
the loop is able to iterate over all handlers in the stack.

mysql-test/r/view.result:
  Add test case result for Bug#48449.
mysql-test/std_data/bug48449.frm:
  Add a incomplete view definition that causes a warning to be
  issued.
mysql-test/t/view.test:
  Add test case for Bug#48449
sql/sql_class.cc:
  Iterate over all handlers in the stack.

The problem was that a failure to open a view wasn't being
properly handled. When opening a view with unknown definer,
the open procedure would be treated as successful and would
later crash when attempting to lock the view (which wasn't
opened to begin with).

The solution is to skip further processing when opening a
table if it fails with a fatal error.

mysql-test/r/view.result:
  Add test case result for Bug#47734.
mysql-test/t/view.test:
  Add test case for Bug#47734.
sql/sql_base.cc:
  Skip further processing if opening a table failed due to
  a fatal error (for the statement).

WL#2474 "Multi Range Read: Change the default MRR implementation to implement new MRR interface"
WL#2475 "Batched range read functions for MyISAM/InnoDb"
        "Index condition pushdown for MyISAM/InnoDB"
Igor's fix from sp1r-igor@olga.mysql.com-20080330055902-07614:
  There could be observed the following problems:
  1. EXPLAIN did not mention pushdown conditions from on expressions in the 
  'extra' column.  As a result if a query had no where conditions pushed 
  down to a table, but had on conditions pushed to this table the 'extra' 
  column in the EXPLAIN for the table missed 'using where'.
  2. Conditions for ref access were not eliminated from on expressions 
  though such conditions were eliminated from the where condition.