into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-bug18819


mysql-test/r/innodb_mysql.result:
  Auto merged
sql/sql_delete.cc:
  Auto merged
mysql-test/include/mix1.inc:
  Auto merged

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug18819


mysql-test/r/innodb_mysql.result:
  Manual merge.
mysql-test/t/innodb_mysql.test:
  Manual merge.
sql/sql_delete.cc:
  Manual merge.

If the error happens during DELETE IGNORE, nothing could be send to the
client, thus leaving it frozen expecting the reply.

The problem was that if some error occurred, it wouldn't be reported to
the client because of IGNORE, but neither success would be reported.

MySQL 4.1 would not freeze the client, but will report

  ERROR 1105 (HY000): Unknown error

instead, which is also a bug.

The solution is to report success if we are in DELETE IGNORE and some
non-fatal error has happened.


mysql-test/r/innodb_mysql.result:
  Add result for bug#18819: DELETE IGNORE hangs on foreign key parent
  delete.
mysql-test/t/innodb_mysql.test:
  Add test case for bug#18819: DELETE IGNORE hangs on foreign key parent
  delete.
sql/sql_delete.cc:
  Report success if we have got an error, but we are in DELETE IGNORE, and
  the error is not fatal (if it is, it would be reported to the client).

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-bug21856


sql/sql_parse.cc:
  Auto merged
mysql-test/r/ps.result:
  Manual merge.
mysql-test/t/ps.test:
  Manual merge.
sql/sql_prepare.cc:
  Manual merge.

When statement to be prepared contained CREATE PROCEDURE, CREATE FUNCTION
or CREATE TRIGGER statements with a syntax error in it, the preparation
would fail with syntax error message, but the memory could be corrupted.

The problem occurred because we switch memroot when parse stored
routine or trigger definitions, and on parse error we restored the
original memroot only after performing some memory operations.  In more
detail:
 - prepared statement would activate its own memory root to parse
   the definition of the stored procedure.
 - SP would reset this memory root with its own memory root to
   parse SP statements
 - a syntax error would happen
 - prepared statement would restore the original memory root
 - stored procedure would restore what it thinks was the original
   memory root, but actually was the statement memory root.
That led to double free - in destruction of the statement and in
a next call to mysql_parse().

The solution is to restore memroot right after the failed parsing.


mysql-test/r/ps.result:
  Add result for bug#21856: Prepared Statements: crash if bad create.
mysql-test/t/ps.test:
  Add test case for bug#21856: Prepared Statements: crash if bad create.
sql/sql_parse.cc:
  On parse error if thd->lex->sphead is set we have to free sp_head object
  to restore statement memroot, if it was switched during parsing.
  
  The change here is for safety, currently query_cache_abort() and
  lex->unit.cleanup() calls do not use current memroot.
sql/sql_prepare.cc:
  On parse error if thd->lex->sphead is set we have to free sp_head object
  to restore statement memroot, if it was switched during parsing.

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-bug21726


mysql-test/r/rpl_insert_id.result:
  Auto merged
mysql-test/t/rpl_insert_id.test:
  Auto merged
sql/item_func.cc:
  Auto merged
sql/item_func.h:
  Auto merged
sql/log_event.cc:
  Auto merged
sql/set_var.cc:
  Auto merged
sql/sql_class.h:
  Auto merged
sql/sql_insert.cc:
  Auto merged
sql/sql_load.cc:
  Auto merged
sql/sql_parse.cc:
  Auto merged
sql/sql_select.cc:
  Auto merged
sql/sql_update.cc:
  Auto merged
tests/mysql_client_test.c:
  Auto merged

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21726


mysql-test/r/rpl_insert_id.result:
  Use local.
mysql-test/t/rpl_insert_id.test:
  Use local.
sql/item_func.cc:
  Use local.
sql/item_func.h:
  Use local.
sql/log_event.cc:
  Use local.
sql/set_var.cc:
  Use local.
sql/sql_class.h:
  Use local.
sql/sql_insert.cc:
  Use local.
sql/sql_load.cc:
  Use local.
sql/sql_parse.cc:
  Use local.
sql/sql_select.cc:
  Use local.
sql/sql_update.cc:
  Use local.
tests/mysql_client_test.c:
  Use local.

mysql-test/r/sp-error.result:
  After merge fix.
mysql-test/t/sp-error.test:
  Fix delimiter restoration.

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-bug20953


mysql-test/r/view.result:
  Auto merged
mysql-test/t/sp-error.test:
  Auto merged
mysql-test/t/view.test:
  Auto merged
sql/sql_lex.cc:
  Auto merged
sql/sql_lex.h:
  Auto merged
sql/sql_view.cc:
  Auto merged
sql/sql_yacc.yy:
  Auto merged
mysql-test/r/sp-error.result:
  Manual merge.

           should fail to create

The problem was that this type of errors was checked during view
creation, which doesn't happen when CREATE VIEW is a statement of
a created stored routine.

The solution is to perform the checks at parse time.  The idea of the
fix is that the parser checks if a construction just parsed is allowed
in current circumstances by testing certain flags, and this flags are
reset for VIEWs.

The side effect of this change is that if the user already have
such bogus routines, it will now get a error when trying to do

  SHOW CREATE PROCEDURE proc;

(and some other) and when trying to execute such routine he will get

  ERROR 1457 (HY000): Failed to load routine test.p5. The table mysql.proc is missing, corrupt, or contains bad data (internal code -6)

However there should be very few such users (if any), and they may
(and should) drop these bogus routines.


mysql-test/r/sp-error.result:
  Add result for bug#20953: create proc with a create view that uses
  local vars/params should fail to create.
mysql-test/r/view.result:
  Update results.
mysql-test/t/sp-error.test:
  Add test case for bug#20953: create proc with a create view that uses
  local vars/params should fail to create.
mysql-test/t/view.test:
  Add second test for variable in a view.
  Remove SP variable in a view test, as it tests wrong behaviour.
  Add test for derived table in a view.
sql/sql_lex.cc:
  Remove LEX::variables_used.
sql/sql_lex.h:
  Remove LEX::variables_used and add st_parsing_options structure and
  LEX::parsing_options member.
sql/sql_view.cc:
  Move some error checking to sql/sql_yacc.yy.
sql/sql_yacc.yy:
  Check for disallowed syntax in a CREATE VIEW at parse time to rise a
  error when it is used inside CREATE PROCEDURE and CREATE FUNCTION, as
  well as by itself.

into  example.com:/work/mysql-5.1-runtime

sql/mysql_priv.h:
  synchronize definition and declaration

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-bug21354

into  example.com:/work/mysql-5.1-runtime

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-bug21354

  This decoupling allows in further versions of MySQL enum interval_type to
  be reordered without this affecting any backward compatibility in the
  events code.
  This changeset doesn't change any exposed behavior but makes events' code
  more durable to changes outside of their code base.
  
  To the reviewer: There is no regression test included as it is impossible
  to construct one with the current infrastructure which can test it. To test
  the code one has create and event, then change the order of
  enum interval_type in my_time.h, update sql/time.cc, recompile the server
  and run it with scheduler running.


include/my_time.h:
  Add a reminder to keep enum interval_type and
  interval_type_to_name in sync
sql/event_data_objects.cc:
  When loading from disk don't use the integer value of
  mysql.event.interval_field because it could be different of the
  values of enum interval_type, if the latter is reordered in a later
  version of MySQL. Loaded from disk is the string value which is then
  resolved against interval_type_to_name to get the exact enum value we
  need for Event_queue_element::interval.
sql/event_db_repository.cc:
  Use interval_type_to_name from sql/time.cc during storage thus
  decoupling the value stored on disk (the enum) from the integer
  representation in memory. interval_type can be changed and as
  long as interval_type_to_name is kept in sync correct values will
  be saved to disk.
sql/mysql_priv.h:
  add proto of find_string_in_array
sql/strfunc.cc:
  Add a function for searching a LEX_STRING in an array of LEX_STRINGs

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-bug21354


mysql-test/t/func_gconcat.test:
  Auto merged
sql/item_sum.cc:
  Auto merged
sql/item_sum.h:
  Auto merged
mysql-test/r/ps.result:
  Manual merge.
mysql-test/t/ps.test:
  Manual merge.

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21354


mysql-test/t/func_gconcat.test:
  Auto merged
sql/item_sum.cc:
  Auto merged
mysql-test/r/ps.result:
  Manual merge.
mysql-test/t/ps.test:
  Manual merge.
sql/item_sum.h:
  Manual merge.

           statement.

The problem was that during statement re-execution if the result was
empty the old result could be returned for group functions.

The solution is to implement proper cleanup() method in group
functions.


mysql-test/r/ps.result:
  Add result for bug#21354: (COUNT(*) = 1) not working in SELECT inside
  prepared statement.
mysql-test/t/func_gconcat.test:
  Add a comment that the test case is from bug#836.
mysql-test/t/ps.test:
  Add test case for bug#21354: (COUNT(*) = 1) not working in SELECT inside
  prepared statement.
sql/item_sum.cc:
  Call clear() in Item_sum_count::cleanup().
sql/item_sum.h:
  Add comments.
  Add proper cleanup() methods.
  Change Item_sum::no_rows_in_result() to call clear() instead of reset(),
  as the latter also issues add(), and there is nothing to add when there
  are no rows in result.

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-bug19111


sql/sql_base.cc:
  Auto merged
mysql-test/r/view.result:
  Manual merge.
mysql-test/t/view.test:
  Manual merge.

In a trigger or a function used in a statement it is possible to do
SELECT from a table being modified by the statement.  However,
encapsulation of such SELECT into a view and selecting from a view
instead of direct SELECT was not possible.

This happened because tables used by views (which in their turn
were used from functions/triggers) were not excluded from checks
in unique_table() routine as it happens for the rest of tables
added to the statement table list for prelocking.

With this fix we ignore all such tables in unique_table(), thus
providing consistency: inside a trigger or a functions SELECT from
a view may be used where plain SELECT is allowed.  Modification of
the same table from function or trigger is still disallowed.  Also,
this patch doesn't affect the case where SELECT from the table being
modified is done outside of function of trigger, such SELECTs are
still disallowed (this limitation and visibility problem when function
select from a table being modified are subjects of bug 21326).  See
also bug 22427.


mysql-test/r/view.result:
  Add result for bug#19111: TRIGGERs selecting from a VIEW on the
  firing base table fail.
mysql-test/t/view.test:
  Add test case for bug#19111: TRIGGERs selecting from a VIEW on the
  firing base table fail.
sql/sql_base.cc:
  In unique_table() do not check tables that are used in a stored
  function or a trigger ('prelocking_placeholder' is set).  If such
  function or a trigger will attempt to modify a table, the error will
  be given, however select is allowed there.

into  mysql.com:/home/svoj/devel/mysql/engines/mysql-5.1-engines


storage/myisammrg/ha_myisammrg.cc:
  Auto merged

into  may.pils.ru:/home/svoj/devel/bk/mysql-5.1-engines


sql/sql_update.cc:
  Auto merged
sql/share/errmsg.txt:
  Auto merged
storage/csv/ha_tina.cc:
  Auto merged
storage/myisammrg/ha_myisammrg.cc:
  Auto merged
mysql-test/r/windows.result:
  Use remote.
mysql-test/t/windows.test:
  Use remote.

into  mysql.com:/home/svoj/devel/mysql/BUG22937/mysql-5.1-engines


storage/myisammrg/ha_myisammrg.cc:
  Auto merged

into  mysql.com:/home/svoj/devel/mysql/BUG22937/mysql-5.0-engines


sql/ha_myisammrg.cc:
  Manual merge.

into  mysql.com:/home/svoj/devel/mysql/BUG22937/mysql-4.1-engines

This is addition to fix for bug21617. Valgrind reports an error when
opening merge table that has underlying tables with less indexes than
in a merge table itself.

Copy at most min(file->keys, table->key_parts) elements from rec_per_key array.
This fixes problems when merge table and subtables have different number of keys.


sql/ha_myisammrg.cc:
  Copy at most min(file->keys, table->key_parts) elements from rec_per_key array.
  This fixes problems when merge table and subtables have different number of keys.

into  mysql.com:/home/svoj/devel/mysql/BUG21381/mysql-5.1-engines


mysql-test/r/ndb_update.result:
  SCCS merged

into  mysql.com:/home/svoj/devel/mysql/BUG21381/mysql-5.0-engines


mysql-test/r/ndb_update.result:
  Auto merged
mysql-test/t/ndb_update.test:
  Auto merged

Note: bug#21726 does not directly apply to 4.1, as it doesn't have stored
procedures.  However, 4.1 had some bugs that were fixed in 5.0 by the
patch for bug#21726, and this patch is a backport of those fixes.
Namely, in 4.1 it fixes:

  - LAST_INSERT_ID(expr) didn't return value of expr (4.1 specific).

  - LAST_INSERT_ID() could return the value generated by current
    statement if the call happens after the generation, like in

      CREATE TABLE t1 (i INT AUTO_INCREMENT PRIMARY KEY, j INT);
      INSERT INTO t1 VALUES (NULL, 0), (NULL, LAST_INSERT_ID());

  - Redundant binary log LAST_INSERT_ID_EVENTs could be generated.


mysql-test/r/rpl_insert_id.result:
  Add result for bug#21726: Incorrect result with multiple invocations
  of LAST_INSERT_ID.
mysql-test/t/rpl_insert_id.test:
  Add test case for bug#21726: Incorrect result with multiple invocations
  of LAST_INSERT_ID.
sql/item_func.cc:
  Add implementation of Item_func_last_insert_id::fix_fields(), where we
  set THD::last_insert_id_used when statement calls LAST_INSERT_ID().
  In Item_func_last_insert_id::val_int(), return THD::current_insert_id
  if called like LAST_INSERT_ID(), otherwise return value of argument if
  called like LAST_INSERT_ID(expr).
sql/item_func.h:
  Add declaration of Item_func_last_insert_id::fix_fields().
sql/log_event.cc:
  Do not set THD::last_insert_id_used on LAST_INSERT_ID_EVENT.  Though we
  know the statement will call LAST_INSERT_ID(), it wasn't called yet.
sql/set_var.cc:
  In sys_var_last_insert_id::value_ptr(), set THD::last_insert_id_used,
  and return THD::current_insert_id for @@LAST_INSERT_ID.
sql/sql_class.h:
  Update comments.
  Remove THD::insert_id(), as it has lost its purpose now.
sql/sql_insert.cc:
  Now it is OK to read THD::last_insert_id directly.
sql/sql_load.cc:
  Now it is OK to read THD::last_insert_id directly.
sql/sql_parse.cc:
  In mysql_execute_command(), remember THD::last_insert_id (first
  generated value of the previous statement) in THD::current_insert_id,
  which then will be returned for LAST_INSERT_ID() and @@LAST_INSERT_ID.
sql/sql_select.cc:
  If "IS NULL" is replaced with "= <LAST_INSERT_ID>", use right value,
  which is THD::current_insert_id, and also set THD::last_insert_id_used
  to issue binary log LAST_INSERT_ID_EVENT.
sql/sql_update.cc:
  Now it is OK to read THD::last_insert_id directly.
tests/mysql_client_test.c:
  Add test case for bug#21726: Incorrect result with multiple invocations
  of LAST_INSERT_ID.

into  mysql.com:/home/svoj/devel/mysql/BUG10974/mysql-5.1-engines


mysql-test/r/merge.result:
  Manual merge.
sql/share/errmsg.txt:
  Manual merge.

into  mysql.com:/home/svoj/devel/mysql/BUG10974/mysql-5.0-engines


BitKeeper/deleted/.del-errmsg.txt~f96b7055cac394e:
  Auto merged
mysql-test/r/merge.result:
  Manual merge.