causes full table lock on innodb table.
Also fixes Bug#28502 Triggers that update another innodb table 
will block on X lock unnecessarily (duplciate).
Code review fixes.

Both bugs' synopses are misleading: InnoDB table is
not X locked. The statements, however, cannot proceed concurrently, 
but this happens due to lock conflicts for tables used in triggers,
not for the InnoDB table. 

If a user had an InnoDB table, and two triggers, AFTER UPDATE and 
AFTER INSERT, competing for different resources (e.g. two distinct
MyISAM tables), then these two triggers would not be able to execute
concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would
not be able to run concurrently. 
The problem had other side-effects (see respective bug reports).

This behavior was a consequence of a shortcoming of the pre-locking
algorithm, which would not distinguish between different DML operations
(e.g. INSERT and DELETE) and pre-lock all the tables
that are used by any trigger defined on the subject table.

The idea of the fix is to extend the pre-locking algorithm to keep track,
for each table, what DML operation it is used for and not
load triggers that are known to never be fired.


mysql-test/r/trigger-trans.result:
  Update results (Bug#26141)
mysql-test/r/trigger.result:
  Update results (Bug#28502)
mysql-test/t/trigger-trans.test:
  Add a test case for Bug#26141 mixing table types in trigger causes 
  full table lock on innodb table.
mysql-test/t/trigger.test:
  Add a test case for Bug#28502 Triggers that update another innodb 
  table will block echo on X lock unnecessarily. Add more test 
  coverage for triggers.
sql/item.h:
  enum trg_event_type is needed in table.h
sql/sp.cc:
  Take into account table_list->trg_event_map when determining
  what tables to pre-lock. 
  
  After this change, if we attempt to fire a 
  trigger for which we had not pre-locked any tables, error
  'Table was not locked with LOCK TABLES' will be printed.
  This, however, should never happen, provided the pre-locking
  algorithm has no programming bugs.
  
  Previously a trigger key in the sroutines hash was based on the name 
  of the table the trigger belongs to. This was possible because we would
  always add to the pre-locking list all the triggers defined for a table when
  handling this table.
  Now the key is based on the name of the trigger, owing
  to the fact that a trigger name must be unique in the database it
  belongs to.
sql/sp_head.cc:
  Generate sroutines hash key in init_spname(). This is a convenient
  place since there we have all the necessary information and can
  avoid an extra alloc.
  
  Maintain and merge trg_event_map when adding and merging elements
  of the pre-locking list.
sql/sp_head.h:
  Add ,m_sroutines_key member, used when inserting the sphead for a
  trigger into the cache of routines used by a statement.
  Previously the key was based on the table name the trigger belonged
  to, since for a given table we would add to the sroutines list
  all the triggers defined on it.
sql/sql_lex.cc:
  Introduce a new lex step: set_trg_event_type_for_tables().
  It is called when we have finished parsing but before opening
  and locking tables. Now this step is used to evaluate for each
  TABLE_LIST instance which INSERT/UPDATE/DELETE operation, if any,
  it is used in.
  In future this method could be extended to aggregate other information
  that is hard to aggregate during parsing.
sql/sql_lex.h:
  Add declaration for set_trg_event_type_for_tables().
sql/sql_parse.cc:
  Call set_trg_event_type_for_tables() after MYSQLparse(). Remove tabs.
sql/sql_prepare.cc:
  Call set_trg_event_type_for_tables() after  MYSQLparse().
sql/sql_trigger.cc:
  Call set_trg_event_type_for_tables() after MYSQLparse().
sql/sql_trigger.h:
  Remove an obsolete member.
sql/sql_view.cc:
  Call set_trg_event_type_for_tables() after MYSQLparse().
sql/sql_yacc.yy:
  Move assignment of sp_head::m_type before calling sp_head::init_spname(), 
  one is now used inside another.
sql/table.cc:
  Implement TABLE_LIST::set_trg_event_map() - a method that calculates
  wh triggers may be fired on this table when executing a statement.
sql/table.h:
  Add missing declarations.
  Move declaration of trg_event_type from item.h (it will be needed for 
  trg_event_map bitmap when we start using Bitmap template instead
  of uint8).

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


sql/sql_lex.cc:
  Auto merged
sql/sql_lex.h:
  Auto merged

The need arose when working on Bug 26141, where it became
necessary to replace TABLE_LIST with its forward declaration in a few
headers, and this involved a lot of s/TABLE_LIST/st_table_list/.
Although other workarounds exist, this patch is in line
with our general strategy of moving away from typedef-ed names.
Sometime in future we might also rename TABLE_LIST to follow the
coding style, but this is a huge change.


sql/item.cc:
  st_table_list -> TABLE_LIST
sql/item.h:
  st_table_list -> TABLE_LIST
sql/mysql_priv.h:
  st_table_list -> TABLE_LIST
sql/sql_base.cc:
  st_table_list -> TABLE_LIST
sql/sql_lex.cc:
  st_table_list -> TABLE_LIST
sql/sql_lex.h:
  st_table_list -> TABLE_LIST
sql/sql_select.cc:
  st_table_list -> TABLE_LIST
sql/sql_show.cc:
  st_table_list -> TABLE_LIST
sql/sql_udf.h:
  Was not needed.
sql/table.cc:
  st_table_list -> TABLE_LIST
sql/table.h:
  st_table_list -> TABLE_LIST

fails if a database is not selected prior.

The problem manifested itself when a user tried to
create a routine that had non-fully-qualified identifiers in its bodies
and there was no current database selected.

This is a regression introduced by the fix for Bug 19022:

The patch for Bug 19022 changes the code to always produce a warning
if we can't resolve the current database in the parser. 
In this case this was not necessary, since even though the produced
parsed tree was incorrect, we never re-use sphead
that was obtained at first parsing of CREATE PROCEDURE.
The sphead that is anyhow used is always obtained through db_load_routine,
and there we change the current database to sphead->m_db before
calling yyparse.

The idea of the fix is to resolve the current database directly using 
lex->sphead->m_db member when parsing a stored routine body, when
such is present.

This patch removes the need to reset the current database
when loading a trigger or routine definition into SP cache.
The redundant code will be removed in 5.1.


mysql-test/r/sp.result:
  Update test results (Bug#29050)
mysql-test/r/trigger.result:
  Update results.
mysql-test/t/sp.test:
  Add a test case for Bug#29050
mysql-test/t/trigger.test:
  Fix wrong behavior covered with tests.
sql/sql_lex.cc:
  Implement st_lex::copy_db_to().
sql/sql_lex.h:
  Declare st_lex::copy_db_to().
sql/sql_parse.cc:
  Use st_lex::copy_db_to() in add_table_to_list, rather than
  THD::copy_db_to(). The former will use the database of the sphead,
  if we're parsing a stored routine, not the default database in
  THD. The default database is needed to initialize tables->db
  when the database part was not explicitly specified in the identifier.
sql/sql_yacc.yy:
  Use st_lex::copy_db_to() in the parser, rather than
  THD::copy_db_to(). The former will use the database of the sphead,
  if we're parsing a stored routine, not the default database in
  THD.

'No database selected' is reported when calling stored procedures

Remove the offending warning introduced by the fix for Bug
25082
This minimal patch relies on the intrinsic knowledge of the fact that
mysql_change_db is never called with 'force_switch' set to TRUE
when such a warning may be needed:
 * every stored routine belongs to a database (unlike, e.g., a 
user defined function, which does not), so if we're activating the
database of a stored routine, it can never be NULL.
Therefore, this branch is never called for activation.
 * if we're restoring the 'old' current database after routine
execution is complete, we should not issue a warning, since it's OK to 
call a routine without having previously selected the current database.

TODO: 'force_switch' is an ambiguous flag, since we do not actually
have to 'force' the switch in case of stored routines at all.
When we activate the routine's database, we should perform
all the checks as in case of 'use db', and so we already do (in this
case 'force_switch' is unused).
When we load a routine into cache, we should not use mysql_change_db
at all, since there it's enough to call thd->reset_db(). We
do it this way for triggers, but code for routines is different (wrongly). 

TODO: bugs are lurking in replication, since it bypasses mysql_change_db
and calls thd->[re_]set_db to set the current database.
The latter does not change thd->db_charset, thd->sctx->db_access
and thd->variables.collation_database (and this may have nasty side
effects).

These todo items are to be addressed in a separate patch, if at all.


mysql-test/r/sp.result:
  Update results (Bug#28551)
mysql-test/t/sp.test:
  Add a test case (Bug#28551)
sql/sp.cc:
  Remove an obsolete comment.
  Replace a check with an assert.
sql/sql_db.cc:
  Remove the offending warning introduced by the fix for Bug
  25082
  This minimal patch relies on the intrinsic knowledge of the fact that
  mysql_change_db is never called with 'force_switch' set to TRUE
  when such a warning may be needed.

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


sql/sql_class.h:
  Auto merged
sql/sql_parse.cc:
  Auto merged

mysql-test/r/ps_6bdb.result:
  Update test results (character sets patch).

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


mysql-test/r/type_enum.result:
  Auto merged
mysql-test/t/type_enum.test:
  Auto merged
sql/field_conv.cc:
  SCCS merged

into  gleb.loc:/home/uchum/work/bk/5.0-opt

When a UNION statement forced conversion of an UTF8
charset value to a binary charset value, the byte
length of the result values was truncated to the
CHAR_LENGTH of the original UTF8 value.


sql/item.cc:
  Fixed bug #29205.
  The calculation of data length was modified in
  the Item_type_holder::join_types method to take into
  account possible conversion of a multibyte charset
  value to a binary charset value, when each
  multibyte character is converted into a sequence
  of bytes (not to a single byte of binary charset).
mysql-test/t/ctype_utf8.test:
  Updated test case for bug #29205.
mysql-test/r/ctype_utf8.result:
  Updated test case for bug #29205.

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

spaces.

When the my_strnncollsp_simple function compares two strings and one is a prefix
of another then this function compares characters in the rest of longer key
with the space character to find whether the longer key is greater or less.
But the sort order of the collation isn't used in this comparison. This may
lead to a wrong comparison result, wrongly created index or wrong order of the
result set of a query with the ORDER BY clause.

Now the my_strnncollsp_simple function uses collation sort order to compare
the characters in the rest of longer key with the space character.


mysql-test/t/ctype_collate.test:
  Added a test case for the bug#29261: Sort order of the collation wasn't used
  when comparing trailing spaces.
mysql-test/r/ctype_collate.result:
  Added a test case for the bug#29261: Sort order of the collation wasn't used
  when comparing trailing spaces.
strings/ctype-simple.c:
  Bug#29261: Sort order of the collation wasn't used when comparing trailing
  spaces.
  Now the my_strnncollsp_simple function uses collation sort order to compare
  the characters in the rest of longer key with the space character.

mysql-test/r/ps_6bdb.result:
  Update result file.
mysql-test/r/ps_7ndb.result:
  Update result file.

mysql-test/r/ps_1general.result:
  Update result file.
mysql-test/r/ps_2myisam.result:
  Update result file.
mysql-test/r/ps_3innodb.result:
  Update result file.
mysql-test/r/ps_4heap.result:
  Update result file.
mysql-test/r/ps_5merge.result:
  Update result file.
tests/mysql_client_test.c:
  Fix test -- after field changing character set to utf8 in the server,
  length should be calculated differently.

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

query / no aggregate of subquery
 The optimizer counts the aggregate functions that 
 appear as top level expressions (in all_fields) in 
 the current subquery. Later it makes a list of these
 that it uses to actually execute the aggregates in
 end_send_group().
 That count is used in several places as a flag whether
 there are aggregates functions.
 While collecting the above info it must not consider
 aggregates that are not aggregated in the current 
 context. It must treat them as normal expressions 
 instead. Not doing that leads to incorrect data about
 the query, e.g. running a query that actually has no
 aggregate functions as if it has some (and hence is
 expected to return only one row).
 Fixed by ignoring the aggregates that are not aggregated
 in the current context. 
 One other smaller omission discovered and fixed in the 
 process : the place of aggregation was not calculated for
 user defined functions. Fixed by calling 
 Item_sum::init_sum_func_check() and 
 Item_sum::check_sum_func() as it's done for the rest of 
 the aggregate functions.


mysql-test/r/subselect.result:
  Bug #27333: test case
mysql-test/t/subselect.test:
  Bug #27333: test case
sql/item_subselect.cc:
  Bug#27333: need select_lex to filter out
   aggregates that are not aggregated in
   the current select.
sql/item_sum.cc:
  Bug#27333: need select_lex to filter out
   aggregates that are not aggregated in
   the current select.
sql/item_sum.h:
  Bug#27333: calculate the place of 
   aggregation for user defined functions.
sql/sql_select.cc:
  Bug#27333: When counting the aggregated functions
   and collecting a list of them we must not consider
   the aggregates that are not aggregated in the local
   context as "local" : i.e. we must treat them as 
   normal functions and not add them to the aggregate
   functions list.
sql/sql_select.h:
  Bug#27333: need select_lex to filter out
   aggregates that are not aggregated in
   the current select.

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


sql-common/client.c:
  Auto merged

SHOW CREATE TABLE or SELECT FROM I_S.

Actually, the bug discovers two problems:
  - the original query is not preserved properly. This is the problem
    of BUG#16291;
  - the resultset of SHOW CREATE TABLE statement is binary.

This patch fixes the second problem for the 5.0.

Both problems will be fixed in 5.1.


mysql-test/r/show_check.result:
  Update result file.
mysql-test/t/show_check.test:
  Provide test case for BUG#10491.
sql/item.h:
  Use utf8_general_ci instead of binary collation by default,
  because for views and base tables utf8 is the character set
  in which their definition is stored. For system constants
  it's the default character set, and for other objects
  (routines, triggers), no character set is stored, and
  therefore no character set is known, so returning utf8
  is just as good as any non-binary character set.
  This latter problem is fixed in 5.1 by 16291. In 5.1
  we will return the "real" character set.

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

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

into  dl145s.mysql.com:/dev/shm/mhansson/my50-bug28677


sql/sql_class.h:
  Auto merged
sql/sql_insert.cc:
  Auto merged
sql/sql_select.cc:
  Auto merged

  
  Thanks to Martin Friebe for finding and submitting a fix for this bug!
  
  A table with maximum number of key segments and maximum length key name
  would have a corrupted .frm file, due to an incorrect calculation of the
  complete key length.  Now the key length is computed correctly (I hope) :-)
  
  MyISAM would reject a table with the maximum number of keys and the maximum
  number of key segments in all keys.  It would allow one less than this total
  maximum.  Now MyISAM accepts a table defined with the maximum.  (This is a
  very minor issue.)


myisam/mi_open.c:
  Bug #26642: change >= to > in a comparison (i.e., error 
  only if key_parts_in_table really is greater than 
  MAX_KEY * MAX_KEY_SEG)
mysql-test/r/create.result:
  Bug #26642: test case
mysql-test/t/create.test:
  Bug #26642: test case
sql/table.cc:
  Bug #26642: In create_frm(), fix formula for key_length; 
  it was too small by (keys * 2) bytes

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

Sometimes special 0 ENUM values was ALTERed to normal
empty string ENUM values.

Special 0 ENUM value has the same string representation
as normal ENUM value defined as '' (empty string).
The do_field_string function was used to convert
ENUM data at an ALTER TABLE request, but this
function doesn't care about numerical "indices" of
ENUM values, i.e. do_field_string doesn't distinguish
a special 0 value from an empty string value.

A new copy function called do_field_enum has been added to
copy special 0 ENUM values without conversion to an empty
string.


sql/field_conv.cc:
  Fixed bug #29251.
  The Copy_field::get_copy_func method has been modified to
  return a pointer to the do_field_enum function if a conversion
  between two columns of incompatible enum types is required.
  The do_field_enum function has been added for the correct
  conversion of special 0 enum values.
mysql-test/t/type_enum.test:
  Updated test case for bug #29251.
mysql-test/r/type_enum.result:
  Updated test case for bug #29251.

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

a lookup into a BINARY index by a key ended with spaces. It caused
an assertion abort for a debug version and wrong results for non-debug
versions.

The problem occurred because the function _mi_pack_key stripped off 
the trailing spaces from binary search keys while the function _mi_make_key
did not do it when keys were inserted into the index.

Now the function _mi_pack_key does not remove the trailing spaces from
search keys if they are of the binary type.


mysql-test/r/binary.result:
  Added a test case for bug #29087.
mysql-test/t/binary.test:
  Added a test case for bug #29087.

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


sql/sql_yacc.yy:
  Auto merged

If one sets MYSQL_READ_DEFAULTS_FILE and MYSQL_READ_DEFAULT_GROUP options
after mysql_real_connect() called with that MYSQL instance,
these options will affect next mysql_reconnect then.
As we use a copy of the original MYSQL object inside mysql_reconnect,
and mysql_real_connect frees options.my_cnf_file and _group strings,
we will free these twice when we execute mysql_reconnect with the
same MYSQL for the second time.

I don't think we should ever read defaults files handling mysql_reconnect.
So i just set them to 0 for the temporary MYSQL object there/


sql-common/client.c:
  Bug #29247 Double free in libmysqlclient_r when mysql restarted.
  
  we don't need mysql_real_connect to reread defaults file in this
  case, so set related parameters to zero

into  gleb.loc:/home/uchum/work/bk/5.0-opt

into  gleb.loc:/home/uchum/work/bk/5.0-opt

into  gleb.loc:/home/uchum/work/bk/4.1-opt

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

  LOCK TABLES takes a list of tables to lock. It may lock several 
  tables successfully and then encounter a tables that it can't lock, 
  e.g. because it's locked. In such case it needs to undo the locks on
  the already locked tables. And it does that. But it has also notified
  the relevant table storage engine handlers that they should lock.
  The only reliable way to ensure that the table handlers will give up
  their locks is to end the transaction. This is what UNLOCK TABLE 
  does : it ends the transaction if there were locked tables by LOCK 
  tables.
  It is possible to end the transaction when the lock fails in 
  LOCK TABLES because LOCK TABLES ends the transaction at its start 
  already. 
  Fixed by ending (again) the transaction when LOCK TABLES fails to
  lock a table.


mysql-test/r/innodb_mysql.result:
  Bug #29154: test case
mysql-test/t/innodb_mysql.test:
  Bug #29154: test case
sql/sql_parse.cc:
  Bug #29154: end the trasaction at a failing 
  LOCK TABLES so the handler can free its locks.

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


sql/sql_select.cc:
  Auto merged

into  gleb.loc:/home/uchum/work/bk/5.0-opt


sql/log_event.cc:
  Auto merged

the loose scan optimization for grouping queries was applied returned 
a wrong result set when the query was used with the SQL_BIG_RESULT
option.

The SQL_BIG_RESULT option forces to use sorting algorithm for grouping
queries instead of employing a suitable index. The current loose scan
optimization is applied only for one table queries when the suitable
index is covering. It does not make sense to use sort algorithm in this
case. However the create_sort_index function does not take into account
the possible choice of the loose scan to implement the DISTINCT operator
which makes sorting unnecessary. Moreover the current implementation of
the loose scan for queries with distinct assumes that sorting will
never happen. Thus in this case create_sort_index should not call
the function filesort.


mysql-test/r/group_min_max.result:
  Added a test case for bug #25602.
mysql-test/t/group_min_max.test:
  Added a test case for bug #25602.

into  gleb.loc:/home/uchum/work/bk/5.0-opt

into  gleb.loc:/home/uchum/work/bk/5.0-opt

INSERT into table from SELECT from the same table
with ORDER BY and LIMIT was inserting other data
than sole SELECT ... ORDER BY ... LIMIT returns.

One part of the patch for bug #9676 improperly pushed
LIMIT to temporary table in the presence of the ORDER BY
clause.
That part has been removed.


sql/sql_select.cc:
  Fixed bug #29095.
  One part of the patch for bug #9676 improperly pushed
  LIMIT to temporary table in the presence of the ORDER BY
  clause.
  That part has been removed.
mysql-test/t/insert_select.test:
  Expanded the test case for bug #9676.
  Created a test case for bug #29095.
mysql-test/r/insert_select.result:
  Expanded the test case for bug #9676.
  Created a test case for bug #29095.

into  trift2.:/MySQL/M50/push-5.0