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

Index lookup does not always guarantee that we can
simply remove the relevant conditions from the WHERE
clause. Reasons can be e.g. conversion errors, 
partial indexes etc. 
The optimizer was removing these parts of the WHERE 
condition without any further checking.
This leads to "false positives" when using indexes.
Fixed by checking the index reference conditions
(using WHERE) when using indexes with sub-queries.

into  moonbone.local:/work/31048-bug-5.0-opt-mysql

  Additional stack check for the bug#31048.

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

8bit escape characters, termination and enclosed characters
were silently ignored by SELECT INTO query, but LOAD DATA INFILE
algorithm is 8bit-clean, so data was corrupted during 
encoding.

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

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

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

into  moonbone.local:/work/31048-bug-5.0-opt-mysql

into  moonbone.local:/work/31048-bug-5.0-opt-mysql

into  moonbone.local:/work/30384-bug-5.0-opt-mysql

led to creating corrupted index.

Corrected fix. The new method called prepare2 is added to the select_create
class. As all preparations are done by the select_create::prepare function
it doesn't do anything. Slightly changed algorithm of calling the 
start_bulk_insert function. Now it's called from the select_insert::prepare2
function when the SQL_BUFFER_RESULT flags is set.
The is_bulk_insert_mode flag is removed as it is not needed anymore.

This bug is actually two. The first one manifests itself on an EXPLAIN
SELECT query with nested subqueries that employs the filesort algorithm.
The whole SELECT under explain is marked as UNCACHEABLE_EXPLAIN to preserve
some temporary structures for explain. As a side-effect of this values of
nested subqueries weren't cached and subqueries were re-evaluated many
times. Each time buffer for filesort was allocated but wasn't freed because
freeing occurs at the end of topmost SELECT. Thus all available memory was
eaten up step by step and OOM event occur.
The second bug manifests itself on SELECT queries with conditions where
a subquery result is compared with a key field and the subquery itself also
has such condition. When a long chain of such nested subqueries is present
the stack overrun occur. This happens because at some point the range optimizer
temporary puts the PARAM structure on the stack. Its size if about 8K and
the stack is exhausted very fast.

Now the subselect_single_select_engine::exec function allows subquery result
caching when the UNCACHEABLE_EXPLAIN flag is set.
Now the SQL_SELECT::test_quick_select function calls the check_stack_overrun
function for stack checking purposes to prevent server crash.

bytes length.

The server has been modified to report warnings on truncation to
65536 bytes as usual.

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

disables the option explicitely.
Changed the option location in code so that --help will show it in
lexical option order.

This is for bug #26215: mysql command line client should not strip
comments from SQL statements

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.