into  adventure.(none):/home/thek/Development/cpp/mysql-5.0-runtime

When a table was explicitly locked with LOCK TABLES no associated
tables from any related trigger on the subject table were locked.
As a result of this the user could experience unexpected locking
behavior and statement failures similar to "failed: 1100: Table'xx'
was not locked with LOCK TABLES".

This patch fixes this problem by making sure triggers are
pre-loaded on any statement if the subject table was explicitly
locked with LOCK TABLES.

between perm and temp tables. Review fixes.

The original bug report complains that if we locked a temporary table
with LOCK TABLES statement, we would not leave LOCK TABLES mode
when this temporary table is dropped.

Additionally, the bug was escalated when it was discovered than
when a temporary transactional table that was previously
locked with LOCK TABLES statement was dropped, futher actions with
this table, such as UNLOCK TABLES, would lead to a crash.

The problem originates from incomplete support of transactional temporary
tables. When we added calls to handler::store_lock()/handler::external_lock()
to operations that work with such tables, we only covered the normal
server code flow and did not cover LOCK TABLES mode. 
In LOCK TABLES mode, ::external_lock(LOCK) would sometimes be called without
matching ::external_lock(UNLOCK), e.g. when a transactional temporary table
was dropped. Additionally, this table would be left in the list of LOCKed 
TABLES.

The patch aims to address this inadequacy. Now, whenever an instance
of 'handler' is destroyed, we assert that it was priorly
external_lock(UNLOCK)-ed. All the places that violate this assert
were fixed.

This patch introduces no changes in behavior -- the discrepancy in
behavior will be fixed when we start calling ::store_lock()/::external_lock()
for all tables, regardless whether they are transactional or not, 
temporary or not.

binary SHOW CREATE TABLE or SELECT FROM I_S.

The problem is that mysqldump generates incorrect dump for a table
with non-ASCII column name if the mysqldump's character set is
ASCII.

The fix is to:
  1. Switch character_set_client for the mysqldump's connection
  to binary before issuing SHOW CREATE TABLE statement in order
  to avoid conversion.
  
  2. Dump switch character_set_client statements to UTF8 and back
  for CREATE TABLE statement.

This allows 5.0 to work with 5.1 databases.

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

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

In sql/sql_yacc.yy, use the %prec construct at the end of rule join_table

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

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

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

into  trift-lap.none:/MySQL/M50/push-5.0

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build

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

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0.46

The Item_date_typecast::val_int function doesn't reset null_value flag.
This makes all values that follows the first null value to be treated as nulls
and led to a wrong result.

Now the Item_date_typecast::val_int function correctly sets the null_value flag
for both null and non-null values.

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

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

a temporary table.

The result string of the Item_func_group_concat wasn't initialized in the 
copying constructor of the Item_func_group_concat class. This led to a
wrong charset of GROUP_CONCAT result when the select employs a temporary
table.

The copying constructor of the Item_func_group_concat class now correctly
initializes the charset of the result string.

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

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

into  bk-internal.mysql.com:/data0/bk/tsmith-tmp/mysql-5.0-maint

for consistency.

No test case, since the bug requires a stress case with 30 INSERT DELAYED
threads and 1 killer thread to repeat. The patch is verified
manually.
Review fixes.

The server that is running DELAYED inserts would deadlock itself
or crash under high load if some of the delayed threads were KILLed
in the meanwhile.

The fix is to change internal lock acquisition order of delayed inserts
subsystem and to ensure that
Delayed_insert::table_list::db does not point to volatile memory in some 
cases.
For details, please see a comment for sql_insert.cc.

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

by renaming "include/md5.h" to "include/my_md5.h".

Fixes bug#14151.

  i5 compatibility

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

For each view the mysqldump utility creates a temporary table
with the same name and the same columns as the view 
in order to satisfy views that depend on this view.
After the creation of all tables, mysqldump drops all
temporary tables and creates actual views.
However, --skip-add-drop-table and --compact flags disable
DROP TABLE statements for those temporary tables. Thus, it was
impossible to create the views because of existence of the
temporary tables with the same names.

  Allow to set mysqld exe suffix

function results in inconsistent behavior.

The bug itself was fixed by the patch for bug 20662.

table (datadir)
Set errno when retunring an error in my_create_with_symlink.

Fix the typo in the constructor. Cover a semantic check that previously
never worked with a test.

table.
The bug itself is yet another manifestation of Bug 26141.

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

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