into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt


sql/item.h:
  Auto merged
sql/sql_base.cc:
  Auto merged
sql/sql_select.cc:
  Auto merged
sql/sql_yacc.yy:
  Auto merged

into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt

into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt


libmysqld/lib_sql.cc:
  Auto merged

into  mysql.com:/home/hf/work/mrg/mysql-4.1-opt

into  mysql.com:/home/hf/work/25492/my50-25492


libmysqld/lib_sql.cc:
  merging

of its argument happened to be a decimal expression returning
the NULL value.
The crash was due to the fact the function in_decimal::set did
not take into account that val_decimal() could return 0 if 
the decimal expression had been evaluated to NULL.  


mysql-test/r/func_in.result:
  Added a test case for bug #27362.
mysql-test/t/func_in.test:
  Added a test case for bug #27362.

into  bodhi.local:/opt/local/work/mysql-5.0-runtime

into  moonbone.local:/mnt/gentoo64/work/23345-bug-5.0-opt-mysql

INTO clause can be specified only for the last select of a UNION and it
receives the result of the whole query. But it was wrongly allowed in
non-last selects of a UNION which leads to a confusing query result.

Now INTO allowed only in the last select of a UNION.


mysql-test/t/union.test:
  Added a test case for the bug#23345: Wrongly allowed INTO in a non-last select of a UNION.
mysql-test/r/union.result:
  Added a test case for the bug#23345: Wrongly allowed INTO in a non-last select of a UNION.
sql/sql_yacc.yy:
  Bug#23345: Wrongly allowed INTO in a non-last select of a UNION.
  Now INTO allowed only in the last select of a UNION.

into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug27257


sql/item_sum.cc:
  Auto merged

aggregated in outer context returned wrong results.
This happened only if the subquery did not contain any references
to outer fields.
As there were no references to outer fields the subquery erroneously
was taken for non-correlated one.
Now any set function aggregated in outer context makes the subquery
correlated.


mysql-test/r/subselect.result:
  Added a test case for bug #27257.
mysql-test/t/subselect.test:
  Added a test case for bug #27257.

into  magare.gmz:/home/kgeorge/mysql/autopush/B24484-5.0


mysql-test/r/subselect3.result:
  Auto merged
sql/item.h:
  Auto merged
sql/item_sum.cc:
  Auto merged
sql/opt_range.cc:
  Auto merged
sql/sql_base.cc:
  Auto merged
sql/sql_class.h:
  Auto merged
sql/sql_insert.cc:
  Auto merged
sql/sql_select.cc:
  Auto merged

To correctly decide which predicates can be evaluated with a given table
the optimizer must know the exact set of tables that a predicate depends 
on. If that mask is too wide (refer to non-existing tables) the optimizer
can erroneously skip a predicate.
One such case of wrong table usage mask were the aggregate functions.
The have a all-1 mask (meaning depend on all tables, including non-existent
ones).
Fixed by making a real used_tables mask for the aggregates. The mask is
constructed in the following way :
1. OR the table dependency masks of all the arguments of the aggregate.
2. If all the arguments of the function are from the local name resolution 
  context and it is evaluated in the same name resolution
  context where it is referenced all the tables from that name resolution 
  context are OR-ed to the dependency mask. This is to denote that an
  aggregate function depends on the number of rows it processes.
3. Handle correctly the case of an aggregate function optimization (such that
  the aggregate function can be pre-calculated and made a constant).

Made sure that an aggregate function is never a constant (unless subject of a 
specific optimization and pre-calculation).  

One other flaw was revealed and fixed in the process : references were 
not calling the recalculation method for used_tables of their targets.


mysql-test/r/subselect3.result:
  Bug #24484: test case
mysql-test/t/subselect3.test:
  Bug #24484: test case
sql/item.h:
  Bug #24484: Item_ref must update the used tables.
sql/item_sum.cc:
  Bug #24484: correct calculation of used_tables for aggregates.
sql/item_sum.h:
  Bug #24484: correct calculation of used_tables for aggregates.
sql/opt_range.cc:
  Bug #24484: fixed ref resolution in loose index scan
sql/sql_base.cc:
  Bug #24484: moved counting of leaf tables inside 
  setup_tables_and_check_access.
sql/sql_class.h:
  Bug #24484: changed table count to more narrow type.
sql/sql_insert.cc:
  Bug #24484: moved counting of leaf tables inside 
  setup_tables_and_check_access. Substract the first
  table (and its subtables) of an INSERT statement
  from leaf_count.
sql/sql_select.cc:
  Bug #24484: correct check for aggregates

  Removed wrong fix for the bug#27006.
  The bug was added by the fix for the bug#19978 and fixed by Monty on 2007/02/21.
trigger.test, trigger.result:
  Corrected test case for the bug#27006.


sql/sql_insert.cc:
  Removed wrong fix for the bug#27006.
  The bug was added by the fix for the bug#19978 and fixed by Monty on 2007/02/21.
mysql-test/t/trigger.test:
  Corrected test case for the bug#27006.
mysql-test/r/trigger.result:
  Corrected test case for the bug#27006.

into  bodhi.local:/opt/local/work/mysql-5.0-runtime


sql/field.cc:
  Auto merged
sql/item.cc:
  Auto merged
sql/item.h:
  Auto merged
sql/item_func.cc:
  Auto merged
sql/sp_head.cc:
  Auto merged
sql/sql_base.cc:
  Auto merged
sql/sql_select.cc:
  Auto merged
sql/sql_show.cc:
  Auto merged
sql/sql_table.cc:
  Auto merged
sql/sql_yacc.yy:
  Auto merged
mysql-test/r/sp.result:
  SCCS merged
mysql-test/t/sp.test:
  SCCS merged

UPDATE if the row wasn't actually changed.

This bug was caused by fix for bug#19978. It causes AFTER UPDATE triggers
not firing if a row wasn't actually changed by the update part of the
INSERT .. ON DUPLICATE KEY UPDATE.

Now triggers are always fired if a row is touched by the INSERT ... ON
DUPLICATE KEY UPDATE.


sql/sql_insert.cc:
  Bug#27006: AFTER UPDATE triggers not fired with INSERT ... ON DUPLICATE KEY
  UPDATE if the row wasn't actually changed.
  Now triggers are always fired if a row is touched by the INSERT ... ON
  DUPLICATE KEY UPDATE.
mysql-test/r/trigger.result:
  Added a test case for the bug#27006: AFTER UPDATE triggers not fired with INSERT ... ON DUPLICATE KEY
  UPDATE if the row wasn't actually changed.
mysql-test/t/trigger.test:
  Added a test case for the bug#27006: AFTER UPDATE triggers not fired with INSERT ... ON DUPLICATE KEY
  UPDATE if the row wasn't actually changed.

into  magare.gmz:/home/kgeorge/mysql/autopush/B26261-5.0-opt


sql/mysql_priv.h:
  Auto merged
sql/sql_insert.cc:
  Auto merged
sql/sql_prepare.cc:
  Auto merged
mysql-test/r/insert_update.result:
  SCCS merged
mysql-test/t/insert_update.test:
  SCCS merged

 INSERT uses query_id to verify what fields are
 mentioned in the fields list of the INSERT command.
 However the check for that is made after the 
 ON DUPLICATE KEY is processed. This causes all
 the fields mentioned in ON DUPLICATE KEY to be 
 considered as mentioned in the fields list of 
 INSERT.
 Moved the check up, right after processing the
 fields list.


mysql-test/r/insert_update.result:
  Bug #26261: test case
mysql-test/t/insert_update.test:
  Bug #26261: test case
sql/mysql_priv.h:
  Bug #26261: moved the check inside mysql_prepare_insert
sql/sql_insert.cc:
  Bug #26261: move the check inside mysql_prepare_insert
  before setting up the ON DUPLICATE KEY part
sql/sql_prepare.cc:
  Bug #26261: moved the check inside mysql_prepare_insert

into  mysql.com:/home/gluh/MySQL/Merge/5.0-opt

The crash happens when 'skip-grant-tables' is enabled.
We skip the filling of I_S privilege tables 
if acl_cache is not initialized.


mysql-test/r/skip_grants.result:
  test result
mysql-test/t/skip_grants.test:
  test case
sql/sql_acl.cc:
  skip filling of I_S privilege tables
  if acl_cache is not initialized

into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt

into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt


sql/sql_parse.cc:
  Auto merged

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

into  moonbone.local:/mnt/gentoo64/work/27033-bug-5.0-opt-mysql

touched but not actually changed.

The LAST_INSERT_ID() is reset to 0 if no rows were inserted or changed.
This is the case when an INSERT ... ON DUPLICATE KEY UPDATE updates a row
with the same values as the row contains.

Now the LAST_INSERT_ID() values is reset to 0 only if there were no rows
successfully inserted or touched.
The new 'touched' field is added to the COPY_INFO structure. It holds the
number of rows that were touched no matter whether they were actually
changed or not.


sql/sql_class.h:
  Bug#27033: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE if rows were
  touched but not actually changed.
  
  The new 'touched' field is added to the COPY_INFO structure. It holds the
  number of rows that were touched no matter whether they were actually
  changed or not.
mysql-test/r/insert_update.result:
  Added a test case for the bug#27033: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE if rows were
  touched but not actually changed.
mysql-test/t/insert_update.test:
  Added a test case for the bug#27033: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE if rows were
  touched but not actually changed.
sql/sql_insert.cc:
  Bug#27033: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE if rows were
  touched but not actually changed.
  
  Now the LAST_INSERT_ID() values is reset to 0 only if there were no rows
  successfully inserted or touched.

into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt


sql/sql_parse.cc:
  Auto merged

into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt


mysql-test/r/gis-rtree.result:
  Auto merged

into  mockturtle.local:/home/dlenev/src/mysql-4.1-merge

into  mockturtle.local:/home/dlenev/src/mysql-5.0-merge

into  mockturtle.local:/home/dlenev/src/mysql-5.0-bg25966-2


sql/mysqld.cc:
  Auto merged

TABLE ... WRITE".

Memory and CPU hogging occured when connection which had to wait for table
lock was serviced by thread which previously serviced connection that was
killed (note that connections can reuse threads if thread cache is enabled).
One possible scenario which exposed this problem was when thread which
provided binlog dump to replication slave was implicitly/automatically
killed when the same slave reconnected and started pulling data through
different thread/connection.
The problem also occured when one killed particular query in connection
(using KILL QUERY) and later this connection had to wait for some table
lock.

This problem was caused by the fact that thread-specific mysys_var::abort
variable, which indicates that waiting operations on mysys layer should
be aborted (this includes waiting for table locks), was set by kill
operation but was never reset back. So this value was "inherited" by the
following statements or even other connections (which reused the same
physical thread). Such discrepancy between this variable and THD::killed
flag broke logic on SQL-layer and caused CPU and memory hogging.

This patch tries to fix this problem by properly resetting this member.

There is no test-case associated with this patch since it is hard to test
for memory/CPU hogging conditions in our test-suite.


sql/mysqld.cc:
  We should not forget to reset THD::mysys_var::abort after kill operation
  if we are going to use thread to which this operation was applied for
  handling of other connections.
sql/sp_head.cc:
  We should not forget to reset THD::mysys_var::abort after kill operation
  if we are going to use thread to which this operation was applied for
  handling of further statements.
sql/sql_parse.cc:
  We should not forget to reset THD::mysys_var::abort after kill operation
  if we are going to use thread to which this operation was applied for
  handling of further statements.

TABLE ... WRITE".

CPU hogging occured when connection which had to wait for table lock was
serviced by thread which previously serviced connection that was killed
(note that connections can reuse threads if thread cache is enabled).
One possible scenario which exposed this problem was when thread which
provided binlog dump to replication slave was implicitly/automatically
killed when the same slave reconnected and started pulling data through
different thread/connection.
In 5.* versions memory hogging was added to CPU hogging. Moreover in
those versions the problem also occured when one killed particular query
in connection (using KILL QUERY) and later this connection had to wait for
some table lock.

This problem was caused by the fact that thread-specific mysys_var::abort
variable, which indicates that waiting operations on mysys layer should
be aborted (this includes waiting for table locks), was set by kill
operation but was never reset back. So this value was "inherited" by the
following statements or even other connections (which reused the same
physical thread). Such discrepancy between this variable and THD::killed
flag broke logic on SQL-layer and caused CPU and memory hogging.

This patch tries to fix this problem by properly resetting this member.

There is no test-case associated with this patch since it is hard to test
for memory/CPU hogging conditions in our test-suite.


sql/mysqld.cc:
  We should not forget to reset THD::mysys_var::abort after kill operation
  if we are going to use thread to which this operation was applied for
  handling of other connections.

into  weblab.(none):/home/marcsql/TREE/mysql-5.0-26503

Before this fix, the parser would accept illegal code in SQL exceptions
handlers, that later causes the runtime to crash when executing the code,
due to memory violations in the exception handler stack.

The root cause of the problem is instructions within an exception handler
that jumps to code located outside of the handler. This is illegal according
to the SQL 2003 standard, since labels located outside the handler are not
supposed to be visible (they are "out of scope"), so any instruction that
jumps to these labels, like ITERATE or LEAVE, should not parse.

The section of the standard that is relevant for this is :
  SQL:2003 SQL/PSM (ISO/IEC 9075-4:2003)
  section 13.1 <compound statement>,
  syntax rule 4
<quote>
  The scope of the <beginning label> is CS excluding every <SQL schema
  statement> contained in CS and excluding every
  <local handler declaration list> contained in CS. <beginning label> shall
  not be equivalent to any other <beginning label>s within that scope.
</quote>

With this fix, the C++ class sp_pcontext, which represent the "parsing
context" tree (a.k.a symbol table) of a stored procedure, has been changed
as follows:
- constructors have been cleaned up, so that only building a root node for
the tree is public; building nodes inside a tree is not public.
- a new member, m_label_scope, indicates if a given syntactic context
belongs to a DECLARE HANDLER block,
- label resolution, in the method find_label(), has been changed to
implement the restriction of scope regarding labels used in a compound
statement.

The actions in the parser, when parsing the body of a SQL exception handler,
have been changed as follows:
- the implementation of an exception handler (DECLARE HANDLER) now creates
explicitly a new sp_pcontext, to isolate the code inside the handler from
the containing compound statement context.
- registering exception handlers as a result occurs in the parent context,
see the rule sp_hcond_element
- the code in sp_hcond_list has been cleaned up, to avoid code duplication

In addition, the flags IN_SIMPLE_CASE and IN_HANDLER, declared in sp_head.h
have been removed, since they are unused and broken by design (as seen with
Bug 19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation), representing a stack in a single flag is not possible.

Tests in sp-error have been added to show that illegal constructs are now
rejected.

Tests in sp have been added for code coverage, to show that ITERATE or LEAVE
statements are legal when jumping to a label in scope, inside the body of
an exception handler.


mysql-test/r/sp-error.result:
  SQL Exception handlers define a parsing context for label resolution.
mysql-test/r/sp.result:
  SQL Exception handlers define a parsing context for label resolution.
mysql-test/t/sp-error.test:
  SQL Exception handlers define a parsing context for label resolution.
mysql-test/t/sp.test:
  SQL Exception handlers define a parsing context for label resolution.
sql/sp_head.cc:
  Minor cleanup
sql/sp_head.h:
  Minor cleanup
sql/sp_pcontext.cc:
  SQL Exception handlers define a parsing context for label resolution.
sql/sp_pcontext.h:
  SQL Exception handlers define a parsing context for label resolution.
sql/sql_yacc.yy:
  SQL Exception handlers define a parsing context for label resolution.

into  mysql.com:/home/kent/bk/tmp/mysql-5.0-build

into  mysql.com:/home/kent/bk/tmp/mysql-4.1-build

  Updated to version 0.6 of the text


EXCEPTIONS-CLIENT:
  Updated to version 0.6 of the text

into  mysql.com:/home/kent/bk/tmp/mysql-5.0-build


configure.in:
  Auto merged