into  linux-st28.site:/home/martin/mysql/src/bug32798-united/my51-bug32798-united-push

a column with null values

Post-merge fix

into  linux-st28.site:/home/martin/mysql/src/bug32798-united/my51-bug32798-united

with null values

For queries containing GROUP_CONCAT(DISTINCT fields ORDER BY fields), there 
was a limitation that the DISTINCT fields had to be the same as ORDER BY 
fields, owing to the fact that one single sorted tree was used for keeping 
track of tuples, ordering and uniqueness. Fixed by introducing a second 
structure to handle uniqueness so that the original structure has only to 
order the result.

into  dl145s.mysql.com:/data0/mhansson/my51-bug32858

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

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

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

into  dl145s.mysql.com:/data0/mhansson/my51-bug32858

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

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

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

into  linux-st28.site:/home/martin/mysql/src/bug32858/my51-bug32858

into  mysql.com:/home/psergey/mysql-5.0-bug32198

- Make conditions like "date_col $CMP$ 'datetime-const'" range-sargable

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

subselects into account

It is forbidden to use the SELECT INTO construction inside UNION statements
unless on the last SELECT of the union. The parser records whether it 
has seen INTO or not when parsing a UNION statement. But if the INTO was
legally used in an outer query, an error is thrown if UNION is seen in a
subquery. Fixed in 5.0 by remembering the nesting level of INTO tokens and 
mitigate the error unless it collides with the UNION.

into  stella.local:/home2/mydev/mysql-5.1-axmrg

Fixed case of comment.

into  stella.local:/home2/mydev/mysql-5.1-axmrg

into  stella.local:/home2/mydev/mysql-5.1-axmrg

into  stella.local:/home2/mydev/mysql-5.1-axmrg

into  stella.local:/home2/mydev/mysql-5.0-axmrg

into  stella.local:/home2/mydev/mysql-5.1-axmrg

into  stella.local:/home2/mydev/mysql-5.1-axmrg

into  stella.local:/home2/mydev/mysql-5.1-axmrg

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

into  stella.local:/home2/mydev/mysql-5.0-axmrg

The patch for Bug 26379 (Combination of FLUSH TABLE and
REPAIR TABLE corrupts a MERGE table) fixed this bug too.
However it revealed a new bug that crashed the server.

Flushing a merge table at the moment when it is between open
and attach of children crashed the server.

The flushing thread wants to abort locks on the flushed table.
It calls ha_myisammrg::lock_count() and ha_myisammrg::store_lock()
on the TABLE object of the other thread.

Changed ha_myisammrg::lock_count() and ha_myisammrg::store_lock()
to accept non-attached children. ha_myisammrg::lock_count() returns
the number of MyISAM tables in the MERGE table so that the memory
allocation done by get_lock_data() is done correctly, even if the
children become attached before ha_myisammrg::store_lock() is
called. ha_myisammrg::store_lock() will not return any lock if the
children are not attached.

This is however a change in the handler interface. lock_count()
can now return a higher number than store_lock() stores locks.
This is more safe than the reverse implementation would be.
get_lock_data() in the SQL layer is adjusted accordingly. It sets
MYSQL_LOCK::lock_count based on the number of locks returned by
the handler::store_lock() calls, not based on the numbers returned
by the handler::lock_count() calls. The latter are only used for
allocation of memory now.

No test case. The test suite cannot reliably run FLUSH between
lock_count() and store_lock() of another thread. The bug report
contains a program that can repeat the problem with some
probability.

into  witty.:/Users/mattiasj/clones/51_push32948

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

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