MySQL and InnoDB dictionaries do not get out of sync.

they are ignored to a new test suite "innodb_plugin".

Remove a hack in mtr that was deployed to run the builtin InnoDB tests against
the InnoDB Plugin. Also detect if a test is an 'innodb plugin test' and if so
then transparently replace the builtin InnoDB with the InnoDB Plugin.

in behavior in InnoDB. The change in behavior was introduced by this
changeset:

  ------------------------------------------------------------
  revno: 3370
  revision-id: vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457
  parent: vasil.dimov@oracle.com-20100331130440-l0y517y3mjsjqy4v
  parent: vasil.dimov@oracle.com-20100331113119-2kbgkaz1d426a43c
  committer: Vasil Dimov <vasil.dimov@oracle.com>
  branch nick: mysql-5.1-innodb
  timestamp: Wed 2010-03-31 16:06:13 +0300
  message:
    Merge from innodb-branches-5.1
      ------------------------------------------------------------
      revno: 0.1.819
      revision-id: vasil.dimov@oracle.com-20100331113119-2kbgkaz1d426a43c
      parent: vasil.dimov@oracle.com-20100331064722-9rc3wypzmer7d6jj
      parent: svn-v4:cee13dc7-1704-0410-992b-c9b4543f1246:branches/5.1:6918
      committer: Vasil Dimov <vasil.dimov@oracle.com>
      branch nick: innodb-branches-5.1
      timestamp: Wed 2010-03-31 14:31:19 +0300
      message:
        Merge from SVN
          ------------------------------------------------------------
          revno: 0.2.1
          revision-id: svn-v4:cee13dc7-1704-0410-992b-c9b4543f1246:branches/5.1:6918
          parent: svn-v4:cee13dc7-1704-0410-992b-c9b4543f1246:branches/5.1:6912
          committer: mmakela
          timestamp: Wed 2010-03-31 07:14:51 +0000
          message:
            branches/5.1: Obey KILL during a lock wait (Bug #51920).
  
            srv_suspend_mysql_thread(), srv_lock_timeout_and_monitor_thread():
            Check trx_is_interrupted() in addition to checking the lock wait timeout.
  
            rb://279 approved by Sunny Bains

The change in behavior was introduced by this changeset:

  ------------------------------------------------------------
  revno: 3405
  revision-id: joro@sun.com-20100317141846-es0qyf5zcqb0hu1c
  parent: davi.arnaut@sun.com-20100309125156-z2c4uyqque49v61k
  committer: Georgi Kodinov <joro@sun.com>
  branch nick: B49838-5.1-bugteam
  timestamp: Wed 2010-03-17 16:18:46 +0200
  message:
    Bug #49838: DROP INDEX and ADD UNIQUE INDEX for same index may corrupt
       definition at engine
    
    If a single ALTER TABLE contains both DROP INDEX and ADD INDEX using 
    the same index name (a.k.a. index modification) we need to disable 
    in-place alter table because we can't ask the storage engine to have 
    two copies of the index with the same name even temporarily (if we 
    first do the ADD INDEX and then DROP INDEX) and we can't modify 
    indexes that are needed by e.g. foreign keys if we first do 
    DROP INDEX and then ADD INDEX.
    Fixed the problem by disabling in-place ALTER TABLE for these cases.
  modified:
    mysql-test/r/innodb_mysql.result sp1f-innodb_mysql.result-20060426055153-bychbbfnqtvmvrwccwhn24i6yi46uqjv
    mysql-test/t/innodb_mysql.test sp1f-innodb_mysql.test-20060816102624-6ymo37d3nyhvbqyzqn5ohsfuydwo426k
    sql/sql_table.cc               sp1f-sql_table.cc-19700101030959-tzdkvgigezpuaxnldqh3fx2h7h2ggslu

Repply changes to storage/innodb_plugin/mysql-test/innodb_bug42101-nonzero-master.opt that were made by MySQL

Move ut_ad() to after declarations for C file.

about wrong innodb_change_buffering value.  Reported by Ranger.

Stick to C90, because some build platforms are not C99 yet.

Fix ./export.sh to honor ENDREV

dict_table_check_for_dup_indexes(): Add the flag tmp_ok.  If !tmp_ok,
check that no index name starts with TEMP_INDEX_PREFIX.

ha_innobase::add_index(), ha_innobase::prepare_drop_index(),
ha_innobase::final_drop_index(): Call dict_table_check_for_dup_indexes().

The problem is that we can not use make_cond_for_table().
This function relies on used_tables() condition
which is not set properly for subqueries.
As result subquery is not filtered out.
The fix is to use remove_eq_conds() function instead
of make_cond_for_table() func. 'remove_eq_conds()'
algorithm relies on const_item() value and it allows
to handle subqueries in right way.

            Procedure, while DECIMAL works

Selecting of the CONCAT(...<SP variable>...) result into
a user variable may return wrong data.


Item_func_concat::val_str contains a number of memory
allocation-saving tricks. One of them concatenates
strings inplace inserting the value of one string
at the beginning of the other string. However,
this trick didn't care about strings those points
to the same data buffer: this is possible when
a CONCAT() parameter is a stored procedure variable -
Item_sp_variable::val_str() uses the intermediate
Item_sp_variable::str_value field, where it may
store a reference to an external buffer.


The Item_func_concat::val_str function has been
modified to take into account val_str functions
(such as Item_sp_variable::val_str) that return
a pointer to an internal Item member variable
that may reference to a buffer provided.

       on index

'my_decimal' class has two members which can be used to access the 
value. The member variable buf (inherited from parent class decimal_t) 
is set to member variable buffer so that both are pointing to same value.

Item_copy_decimal::copy() uses memcpy to clone 'my_decimal'. The member
buffer is declared as an array and memcpy results in copying the values
of the array, but the inherited member buf, which should be pointing at
the begining of the array 'buffer' starts pointing to the begining of 
buffer in original object (which is being cloned). Further updates on 
'my_decimal' updates only the inherited member 'buf' but leaves 
buffer unchanged.

Later when the new object (which now holds a inconsistent value) is cloned
again using proper cloning function 'my_decimal2decimal' the buf pointer
is fixed resulting in loss of the current value.

Using my_decimal2decimal instead of memcpy in Item_copy_decimal::copy()
fixed this problem.