When handling DELETE ... FROM if there is no
condition it is internally transformed to 
TRUNCATE for more efficient execution by the
storage handler.
The check for validity of the optional ORDER BY 
clause is done after the check for the above 
optimization and will not be performed if the
optimization can be applied.
Moved the validity check for ORDER BY before 
the optimization so it performed regardless of
the optimization.

into  dl145s.mysql.com:/users/mhansson/mysql/autopush/5.0o-bug24010

it doesn't select.

This bug was fixed along with bug #16861: User defined variable can 
have a wrong value if a tmp table was used.

There the fix consisted of Item_func_set_user_var overloading the method
Item::save_in_field. Consider the query from the test case:


INSERT INTO foo( bar, baz )
SELECT 
  bar,
  @newBaz := 1 + baz
FROM 
  foo
WHERE 
  quux <= 0.1;

Here the assignment expression '@newBaz := 1 + baz' is represented by an 
Item_func_set_user_var. Its member method save_in_field, which writes the 
value of this assignment into the result field, writes the val_xxx() value, 
which is not updated at this point. In the fix introduced by the patch,
the save_in_field method reads the actual variable value instead.

See also comment for 
ChangeSet@1.2368.1.3, 2007-01-09 23:24:56+03:00, evgen@moonbone.local +4 -0
and comment for
Item_func_set_user_var::save_in_field (item_func.cc)

into  moonbone.local:/mnt/gentoo64/work/23800-bug1-5.0-opt-mysql

created for sorting.

Any outer reference in a subquery was represented by an Item_field object.
If the outer select employs a temporary table all such fields should be
replaced with fields from that temporary table in order to point to the 
actual data. This replacement wasn't done and that resulted in a wrong
subquery evaluation and a wrong result of the whole query.

Now any outer field is represented by two objects - Item_field placed in the
outer select and Item_outer_ref in the subquery. Item_field object is
processed as a normal field and the reference to it is saved in the
ref_pointer_array. Thus the Item_outer_ref is always references the correct
field. The original field is substituted for a reference in the
Item_field::fix_outer_field() function.

New function called fix_inner_refs() is added to fix fields referenced from
inner selects and to fix references (Item_ref objects) to these fields.

The new Item_outer_ref class is a descendant of the Item_direct_ref class.
It additionally stores a reference to the original field and designed to
behave more like a field.

into  rakia.gmz:/home/kgeorge/mysql/autopush/B19717-5.0-opt

into  rakia.gmz:/home/kgeorge/mysql/autopush/B19717-5.0-opt

into  rakia.gmz:/home/kgeorge/mysql/autopush/B25831-5.0-opt

 Several problems fixed: 
  1. There was a "catch-all" context initialization in setup_tables()
    that was causing the table that we insert into to be visible in the 
    SELECT part of an INSERT .. SELECT .. statement with no tables in
    its FROM clause. This was making sure all the under-initialized
    contexts in various parts of the code are not left uninitialized.
    Fixed by removing the "catch-all" statement and initializing the 
    context in the parser.
  2. Incomplete name resolution context when resolving the right-hand
    values in the ON DUPLICATE KEY UPDATE ... part of an INSERT ... SELECT ...
    caused columns from NATURAL JOIN/JOIN USING table references in the
    FROM clause of the select to be unavailable.
    Fixed by establishing a proper name resolution context.
  3. When setting up the special name resolution context for problem 2
    there was no check for cases where an aggregate function without a
    GROUP BY effectively takes the column from the SELECT part of an 
    INSERT ... SELECT unavailable for ON DUPLICATE KEY UPDATE.
    Fixed by checking for that condition when setting up the name 
    resolution context.

into  olga.mysql.com:/home/igor/mysql-5.0-opt

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

UPDATE contains wrong data if the SELECT employs a temporary table.

If the UPDATE values of the INSERT .. SELECT .. ON DUPLICATE KEY UPDATE
statement contains fields from the SELECT part and the select employs a
temporary table then those fields will contain wrong values because they
aren't corrected to get data from the temporary table.

The solution is to add these fields to the selects all_fields list,
to store pointers to those fields in the selects ref_pointer_array and
to access them via Item_ref objects.

The substitution for Item_ref objects is done in the new function called 
Item_field::update_value_transformer(). It is called through the
item->transform() mechanism at the end of the select_insert::prepare()
function.

were evaluated.
According to the new rules for string comparison partial indexes on text
columns can be used in the same cases when partial indexes on varchar
columns can be used.

index_read(), whereas it must return HA_ERR_END_OF_FILE
instead (as there are by definition no rows in a table of 
that engine.

into  bk-internal.mysql.com:/data0/bk/mysql-5.0-opt

into  pilot.mysql.com:/home/msvensson/mysql/mysql-5.0-maint

into  pilot.mysql.com:/home/msvensson/mysql/mysql-5.0-maint

into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug26209

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

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

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

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

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

 Common symbols with and without initialization
 cause the apple linker to exclude then from the
 list of global symbols.

into  mysql.com:/home/tnurnberg/24660/50-24660

into  mysql.com:/home/tnurnberg/24660/41-24660

into  mysql.com:/home/tnurnberg/24660/50-24660

ENUMs weren't allowed to have character 0xff, a perfectly good character in some locales.
This was circumvented by mapping 0xff in ENUMs to ',', thereby prevent actual commas from
being used. Now if 0xff makes an appearance, we find a character not used in the enum and
use that as a separator. If no such character exists, we throw an error.

Any solution would have broken some sort of existing behaviour. This solution should
serve both fractions (those with 0xff and those with ',' in their enums), but
WILL REQUIRE A DUMP/RESTORE CYCLE FROM THOSE WITH 0xff IN THEIR ENUMS. :-/
That is, mysqldump with their current server, and restore when upgrading to one with
this patch.

The crash happens because second filling of the same I_S table happens in
case of subselect with order by. table->sort.io_cache previously allocated
in create_sort_index() is deleted during second filling
(function get_schema_tables_result). There are two places where
I_S table can be filled: JOIN::exec and create_sort_index().
To fix the bug we should check if the table was already filled
in one of these places and skip processing of the table in second.

Some fields (GEOMETRY first of all) can't be handled properly in this
case at all. So we return an error in this case

into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug26159

The function make_unireg_sortorder ignored the fact that any
view field is represented by a 'ref' object.
This could lead to wrong results for the queries containing
both GROUP BY and ORDER BY clauses.

  Post fix for bug#12122.
information_schema.result:
  Corrected test case after fixing bug#12122.

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

A wrong order of statements in QUICK_GROUP_MIN_MAX_SELECT::reset
caused a crash when a query with DISTINCT was executed by a loose scan
for an InnoDB table that had been emptied.