called twice in a row

Queries with nested joins could cause an infinite loop in the
server when used from SP/PS.

When flattening nested joins, simplify_joins() tracks if the
name resolution list needs to be updated by setting
fix_name_res to TRUE if the current loop iteration has done any
transformations to the join table list. The problem was that
the flag was not reset before the next loop iteration leading
to unnecessary "fixing" of the name resolution list which in
turn could lead to a loop (i.e. circularly-linked part) in that
list. This was causing problems on subsequent execution when
used together with stored procedures or prepared statements.

Fixed by making sure fix_name_res is reset on every loop
iteration.

mysql-test/r/join.result:
  Added a test case for bug #53544.
mysql-test/t/join.test:
  Added a test case for bug #53544.
sql/sql_select.cc:
  Make sure fix_name_res is reset on every loop iteration.

            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.


mysql-test/r/join.result:
  Added test cases for bug#55568 and a duplicate bug #54468.
mysql-test/t/join.test:
  Added test cases for bug#55568 and a duplicate bug #54468.
sql/field.cc:
  Make sure field->table_name is not set to NULL in
  Field::make_field() to avoid assertion failure in 
  Item_field::make_field() after cleaning up items
  (the assertion fired in udf.test when running
  the test suite with the patch applied).
sql/sql_select.cc:
  In addition to cleaning up items in tmp_all_fields3, do the
  same for items in tmp_all_fields1.
  Introduce a new helper function to avoid code duplication.
sql/sql_select.h:
  Introduce a new helper function to avoid code duplication in
  JOIN::destroy().

  KILL_BAD_DATA is returned

Two problems discovered with the LEAST()/GREATEST() 
functions:
1. The check for a null value should happen even 
after the second call to val_str() in the args. This is
important because two subsequent calls to the same
Item::val_str() may yield different results.
Fixed by checking for NULL value before dereferencing
the string result.

2. While looping over the arguments and evaluating them 
the loop should stop if there was an error evaluating so far
or the statement was killed. Fixed by checking for error
and bailing out.

So null merge.

        'CREATE TABLE IF NOT EXISTS ... SELECT' behaviour
BUG#55474, BUG#55499, BUG#55598, BUG#55616 and BUG#55777 are fixed
in this patch too.

This is the 5.1 part.
It implements:
- if the table exists, binlog two events: CREATE TABLE IF NOT EXISTS
  and INSERT ... SELECT

- Insert nothing and binlog nothing on master if the existing object
  is a view. It only generates a warning that table already exists.


mysql-test/r/trigger.result:
  Ather this patch, 'CREATE TABLE IF NOT EXISTS ... SELECT' will not
  insert anything if the creating table already exists and is a view.
sql/sql_class.h:
  Declare virtual function write_to_binlog() for select_insert.
  It's used to binlog 'create select'
sql/sql_insert.cc:
  Implement write_to_binlog();
  Use write_to_binlog() instead of binlog_query() to binlog the statement.
  if the table exists, binlog two events: CREATE TABLE IF NOT EXISTS
  and INSERT ... SELECT
sql/sql_lex.h:
  Declare create_select_start_with_brace and create_select_pos.
  They are helpful for binlogging 'create select'
sql/sql_parse.cc:
  Do nothing on master if the existing object is a view.
sql/sql_yacc.yy:
  Record the relative postion of 'SELECT' in the 'CREATE ...SELECT' statement.
  Record whether there is a '(' before the 'SELECT' clause.

     ------------------------------------------------------------
     revno: 3476
     committer: Sunny Bains <Sunny.Bains@Oracle.Com>
     branch nick: 5.1-security
     timestamp: Thu 2010-08-05 19:18:17 +1000
     message:
       Fix bug# 55543 - InnoDB Plugin: Signal 6: Assertion failure in file fil/fil0fil.c line 4306

         The bug is due to a double delete of a BLOB, once via:

               rollback -> btr_cur_pessimistic_delete()

         and the second time via purge.

         The bug is in row_upd_clust_rec_by_insert(). There we relinquish ownership
         of the non-updated BLOB columns in btr_cur_mark_extern_inherited_fields()
         before building the row entry that will be inserted and whose contents will
         be logged in the UNDO log. However, we don't set the BLOB column later to
         INHERITED so that a possible rollback will not free the original row's
         non-updated BLOB entries. This is because the condition that checks for
         that is in :

     		    	if (node->upd_ext) {}.

         node->upd_ext is non-NULL only if a BLOB column was updated and that column
         is part of some key ordering (see row_upd_replace()). This results in the
         non-update BLOB columns being deleted during a rollback and subsequently by
         purge again.

         rb://413

Handle overflow when reading value from SELECT MAX(C) FROM T;

Call ha_innobase::info() after initializing the autoinc value
in ha_innobase::open().

Fix for both the builtin and plugin.

rb://402

Merge from mysql-5.1-security.

variable assignments

The assert() that is firing is checking if expressions that can't be
null return a NULL when evaluated.
MAKEDATE() function can return NULL if the second argument is 
less then or equal to 0. Thus its nullability depends not only on 
the nullability of its arguments but also on their values.
Fixed by (overoptimistically) setting MAKEDATE() to be nullable 
despite the nullability of its arguments.
Test added.
Had to update one test result to reflect the metadata change.

  ------------------------------------------------------------
  revno: 3475
  revision-id: jimmy.yang@oracle.com-20100804103744-vbpeghipkz6pyc9z
  parent: jimmy.yang@oracle.com-20100804101133-c38qqbm0fkwn9jhc
  committer: Jimmy Yang <jimmy.yang@oracle.com>
  branch nick: mysql-5.1-security
  timestamp: Wed 2010-08-04 03:37:44 -0700
  message:
    Fix bug #54678, InnoDB, TRUNCATE, ALTER, I_S SELECT, crash or deadlock
    
    rb://399 approved by Sunny Bains
  modified:
    storage/innodb_plugin/ChangeLog 2425@16c675df-0fcb-4bc9-8058-dcc011a37293:branches%2Fzip%2FChangeLog
    storage/innodb_plugin/include/dict0dict.h 2@16c675df-0fcb-4bc9-8058-dcc011a37293:trunk%2Finclude%2Fdict0dict.h
    storage/innodb_plugin/include/dict0dict.ic 2@16c675df-0fcb-4bc9-8058-dcc011a37293:trunk%2Finclude%2Fdict0dict.ic
    storage/innodb_plugin/row/row0mysql.c 2@16c675df-0fcb-4bc9-8058-dcc011a37293:trunk%2Frow%2Frow0mysql.c

sunny.bains@oracle.com-20100805092434-tvxxzjgqgslo14en

This is a null merge of InnoDB changes which will be ported into a
separate commits.

(this is a null merge)

An user assignment variable expression that's 
evaluated in a logical expression context 
(Item::val_bool()) can be pre-calculated in a 
temporary table for GROUP BY.
However when the expression value is used after the
temp table creation it was re-evaluated instead of
being read from the temp table due to a missing 
val_bool_result() method.
Fixed by implementing the method.

The server was not checking for errors generated during
the execution of Item::val_xxx() methods when copying
data to the group, order, or distinct temp table's row.
Fixed by extending the copy_funcs() to return an error
code and by checking for that error code on the places
copy_funcs() is called. 
Test case added.

Fixing copyright text.