- Removed files specific to compiling on OS/2
- Removed files specific to SCO Unix packaging
- Removed "libmysqld/copyright", text is included in documentation
- Removed LaTeX headers for NDB Doxygen documentation
- Removed obsolete NDB files
- Removed "mkisofs" binaries
- Removed the "cvs2cl.pl" script
- Changed a few GPL texts to use "program" instead of "library"

file .\item_subselect.cc, line 836
     
IN quantified predicates are never executed directly. They are rather wrapped
inside nodes called IN Optimizers (Item_in_optimizer) which take care of the
execution. However, this is not done during query preparation. Unfortunately
the LIKE predicate pre-evaluates constant right-hand side arguments even
during name resolution. Likely this is meant as an optimization.
      
Fixed by not pre-evaluating LIKE arguments in view prepare mode.

Back-ported to 5.0s

The user-visible problem was that changes to column-level privileges,
happened in between of PREPARE and EXECUTE of a prepared statement, were
neglected. I.e. a prepared statement could be executed with the
column-level privileges as of PREPARE-time. The problem existed for
column-level privileges only.

A similar problem existed for stored programs: the changes between
executions didn't have an effect.

Technically the thing is that table references are cached in
Prepared_statement::prepare() call. In subsequent
Prepared_statement::execute() calls those cached values are used.
There are two functions to get a field by name: find_field_in_table() and
find_field_in_table_ref(). On prepare-phase find_field_in_table_ref() is
called, on execute-phase -- find_field_in_table() because the table is
cached. find_field_in_table() does not check column-level privileges and
expects the caller to do that. The problem was that this check was
forgotten.

The fix is to check them there as it happens in find_field_in_table_ref().

Original revid: alexey.kopytov@sun.com-20100723115254-jjwmhq97b9wl932l

 > Bug #54476: crash when group_concat and 'with rollup' in
 >                      prepared statements
 >
 > Using GROUP_CONCAT() together with the WITH ROLLUP modifier
 > could crash the server.
 >
 > The reason was a combination of several facts:
 >
 > 1. The Item_func_group_concat class stores pointers to ORDER
 > objects representing the columns in the ORDER BY clause of
 > GROUP_CONCAT().
 >
 > 2. find_order_in_list() called from
 > Item_func_group_concat::setup() modifies the ORDER objects so
 > that their 'item' member points to the arguments list
 > allocated in the Item_func_group_concat constructor.
 >
 > 3. In some cases (e.g. in JOIN::rollup_make_fields) a copy of
 > the original Item_func_group_concat object could be created by
 > using the Item_func_group_concat::Item_func_group_concat(THD
 > *thd, Item_func_group_concat *item) copy constructor. The
 > latter essentially creates a shallow copy of the source
 > object. Memory for the arguments array is allocated on
 > thd->mem_root, but the pointers for arguments and ORDER are
 > copied verbatim.
 >
 > What happens in the test case is that when executing the query
 > for the first time, after a copy of the original
 > Item_func_group_concat object has been created by
 > JOIN::rollup_make_fields(), find_order_in_list() is called for
 > this new object. It then resolves ORDER BY by modifying the
 > ORDER objects so that they point to elements of the arguments
 > array which is local to the cloned object. When thd->mem_root
 > is freed upon completing the execution, pointers in the ORDER
 > objects become invalid. Those ORDER objects, however, are also
 > shared with the original Item_func_group_concat object which is
 > preserved between executions of a prepared statement. So the
 > first call to find_order_in_list() for the original object on
 > the second execution tries to dereference an invalid pointer.
 >
 > The solution is to create copies of the ORDER objects when
 > copying Item_func_group_concat to not leave any stale pointers
 > in other instances with different lifecycles.

Improved error handling such that queries against Information_Schema.Tables won't
fail if a Federated table is unable to connect to remote host.

will not display "indicated result file not found" due to wrongly named
var directory.

 > revision-id: gshchepa@mysql.com-20100801181236-uyuq6ewaq43rw780
 > parent: alexey.kopytov@sun.com-20100723115254-jjwmhq97b9wl932l
 > committer: Gleb Shchepa <gshchepa@mysql.com>
 > branch nick: mysql-5.1-security
 > timestamp: Sun 2010-08-01 22:12:36 +0400
 > Bug #54461: crash with longblob and union or update with subquery
 >
 > Queries may crash, if
 >   1) the GREATEST or the LEAST function has a mixed list of
 >      numeric and LONGBLOB arguments and
 >   2) the result of such a function goes through an intermediate
 >      temporary table.
 >
 > An Item that references a LONGBLOB field has max_length of
 > UINT_MAX32 == (2^32 - 1).
 >
 > The current implementation of GREATEST/LEAST returns REAL
 > result for a mixed list of numeric and string arguments (that
 > contradicts with the current documentation, this contradiction
 > was discussed and it was decided to update the documentation).
 >
 > The max_length of such a function call was calculated as a
 > maximum of argument max_length values (i.e. UINT_MAX32).
 >
 > That max_length value of UINT_MAX32 was used as a length for
 > the intermediate temporary table Field_double to hold
 > GREATEST/LEAST function result.
 >
 > The Field_double::val_str() method call on that field
 > allocates a String value.
 >
 > Since an allocation of String reserves an additional byte
 > for a zero-termination, the size of String buffer was
 > set to (UINT_MAX32 + 1), that caused an integer overflow:
 > actually, an empty buffer of size 0 was allocated.
 >
 > An initialization of the "first" byte of that zero-size
 > buffer with '\0' caused a crash.
 >
 > The Item_func_min_max::fix_length_and_dec() has been
 > modified to calculate max_length for the REAL result like
 > we do it for arithmetical operators.

Fix formatting issues in README file.

EXCEPTIONS-CLIENT from all the places.

> revision-id: alexey.kopytov@sun.com-20100824103548-ikm79qlfrvggyj9h
> parent: sunny.bains@oracle.com-20100816001222-xqc447tr6jwh8c53
> committer: Alexey Kopytov <Alexey.Kopytov@Sun.com>
> branch nick: 5.1-security
> timestamp: Tue 2010-08-24 14:35:48 +0400
> message:
>   Bug #55568: user variable assignments crash server when used
>               within query
>   
>   The server could crash after materializing a derived table
>   which requires a temporary table for grouping.
>   
>   When destroying the temporary table used to execute a query for
>   a derived table, JOIN::destroy() did not clean up Item_fields
>   pointing to fields in the temporary table. This led to
>   dereferencing a dangling pointer when printing out the items
>   tree later in the outer SELECT.
>   
>   The solution is an addendum to the patch for bug37362: in
>   addition to cleaning up items in tmp_all_fields3, do the same
>   for items in tmp_all_fields1, since now we have an example
>   where this is necessary.

backport from 5.1

Problem: a flaw (derefencing a NULL pointer) in the LIKE optimization
code may lead to a server crash in some rare cases.

Fix: check the pointer before its dereferencing.

Updated the README file.

Fix a regression (due to a typo) which caused spurious incorrect
argument errors for long data stream parameters if all forms of
logging were disabled (binary, general and slow logs).

Calculating the estimated number of records for a range scan
may take a significant time, and it was impossible for a user
to interrupt that process by killing the connection or the
query.

Fixed by checking the thread's 'killed' status in
check_quick_keys() and interrupting the calculation process if
it is set to a non-zero value.