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

Comparison of a BIGINT NOT NULL column with a constant arithmetic
expression that evaluates to NULL caused error 1048: "Column '...'
cannot be null".

Made convert_constant_item() check if the constant expression is NULL
before attempting to store it in a field. Attempts to store NULL in a
NOT NULL field caused query errors.

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

into  mysql.com:/home/hf/work/31158/my41-31158

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

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

into  polly.(none):/home/kaa/src/opt/mysql-5.0-opt

checked for each record'

The problem was in incorrectly calculated length of the buffer used to
store a hexadecimal representation of an index map in
select_describe(). This could result in buffer overrun and stack
corruption under some circumstances.

Fixed by correcting the calculation.

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

Implement neccessary shared lock structure for table locks.
This is the backport of bug26241 fix.

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

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

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

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

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

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

into  mysql.com:/home/hf/work/31305/my41-31305

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

The columns in HAVING can reference the GROUP BY and 
SELECT columns. There can be "table" prefixes when
referencing these columns. And these "table" prefixes
in HAVING use the table alias if available.
This means that table aliases are subject to the same
storage rules as table names and are dependent on 
lower_case_table_names in the same way as the table 
names are.
Fixed by :
1. Treating table aliases as table names
and make them lowercase when printing out the SQL
statement for view persistence.
2. Using case insensitive comparison for table 
aliases when requested by lower_case_table_names

max_length parameter for BLOB-returning functions must be big enough
for any possible content. Otherwise the field created for a table
will be too small.

into  mattiasj-laptop.(none):/home/mattiasj/clones/mysql-5.0-engines_with_main

into  mattiasj-laptop.(none):/home/mattiasj/clones/mysql-5.0-engines_with_main

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

  Use proper variable for test.

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

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

into  polly.(none):/home/kaa/src/opt/mysql-5.0-opt

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

When we insert a record into MYISAM table which is almost 'full',
we first write record data in the free space inside a file, and then
check if we have enough space after the end of the file.
So if we don't have the space, table will left corrupted.
Similar error also happens when we updata MYISAM tables.

Fixed by modifying write_dynamic_record and update_dynamic_record functions
to check for free space before writing parts of a record

into  mysql.com:/misc/mysql/31700/50-31700

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

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

into  polly.(none):/home/kaa/src/opt/mysql-5.0-opt

After adding an index the <VARBINARY> IN (SELECT <BINARY> ...)
clause returned a wrong result: the VARBINARY value was illegally padded
with zero bytes to the length of the BINARY column for the index search.
(<VARBINARY>, ...) IN (SELECT <BINARY>, ... ) clauses are affected too.

into  mysql.com:/misc/mysql/31700/50-31700

UNIQUE (eq-ref) lookups result in table being considered as a "constant" table.
Queries that consist of only constant tables are processed in do_select() in a
special way that doesn't invoke evaluate_join_record(), and therefore doesn't
increase the counters join->examined_rows and join->thd->row_count.

The patch increases these counters in this special case.

NOTICE:
This behavior seems to contradict what the documentation says in Sect. 5.11.4:
"Queries handled by the query cache are not added to the slow query log, nor
are queries that would not benefit from the presence of an index because the
table has zero rows or one row."

No test case in 5.0 as issue shows only in slow query log, and other counters
can give subtly different values (with regard to counting in create_sort_index(),
synthetic rows in ROLLUP, etc.).

into  mysql.com:/scratch/tnurnberg/31800/50-31800