The bug report has demonstrated the following two problems.
1. If an ORDER/GROUP BY list includes a constant expression being 
optimized away and, at the same time, containing single-row
subselects that return more that one row, no error is reported.
Strictly speaking the standard allows to ignore error in this case.
Yet, now a corresponding fatal error is reported in this case.
2. If a query requires sorting by expressions containing single-row
subselects that, however, return more than one row, then the execution
of the query may cause a server crash. 
To fix this some code has been added that blocks execution of a subselect
item in case of a fatal error in the method Item_subselect::exec.

The bug is actually a duplicate of the bug 14708.
Down-ported the fix for 14708 from 5.0.  
Merged the test case for bug 14708 from 5.0.

for queries using 'range checked for each record'.
The problem was fixed in 5.0 by the patch for bug 12291.
This patch down-ported the corresponding code from 5.0 into 
QUICK_SELECT::init() and added a new test case. 

correctly.

The Item_func::print method was used to print the Item_func_encode and the
Item_func_decode objects. The last argument to ENCODE and DECODE functions
is a plain C string and thus Item_func::print wasn't able to print it.

The print() method is added to the Item_func_encode class. It correctly
prints the Item_func_encode and the Item_func_decode objects.

WHERE is present.

If a DELETE statement with ORDER BY and LIMIT contains a WHERE clause
with conditions that for sure cannot be used for index access (like in
WHERE @var:= field) the execution always follows the filesort path.    
It happens currently even when for the above case there is an index that
can be used to speedup sorting by the order by list.

Now if a DELETE statement with ORDER BY and LIMIT contains such WHERE
clause conditions that cannot be used to build any quick select then
the mysql_delete() tries to use an index like there is no WHERE clause at all.

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

2nd version
During tmp tables cleanup we get the handler for temporary table
and delete table using handler method.

In the method Item_field::fix_fields we try to resolve the name of
the field against the names of the aliases that occur in the select
list. This is done by a call of the function find_item_in_list.
When this function finds several occurrences of the field name
it sends an error message to the error queue and returns 0.
Yet the code did not take into account that find_item_in_list
could return 0 and tried to dereference the returned value.

into  mysql.com:/d2/hf/opt/my41-opt

into  mysql.com:/d2/hf/common/my41-common

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

Compiler warnings due to non-matching conversion
specifications in format strings in DBUG_PRINT calls,
due to non-used parameters (in non-debug mode), and
due to seemingly uninitialized variables.

Initialized variables, declared parameters unused, and
casted DBUG_PRINT arguments to get rid of warnings.

Compiler warnings due to non-matching conversion
specifications in format strings in DBUG_PRINT calls.

Fixed DBUG_PRINT format specifiactions.

into  chilla.local:/home/mydev/mysql-4.1-axmrg

into  trift2.:/MySQL/M41/push-4.1

    The Docs team has two new manpages for the "server" RPM: "my_print_defaults" and "mysql_tzinfo_to_sql".

into  kahlann.erinye.com:/home/df/mysql/build/mysql-4.1-build

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

and no WHERE condition were applied for any subquery without tables.

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

into  kahlann.erinye.com:/home/df/mysql/build/mysql-4.1-build

into  chilla.local:/home/mydev/mysql-4.1-axmrg

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

            table

ROW_FORMAT option is lost during CREATE/DROP INDEX.

This fix forces CREATE/DROP INDEX to retain ROW_FORMAT by instructing
mysql_alter_table() that ROW_FORMAT is not used during creating/dropping
indexes.

datafile added to be used in gis.test

The problem is that the GEOMETRY NOT NULL can't automatically set
any value as a default one. We always tried to complete LOAD DATA
command even if there's not enough data in file. That doesn't work
for GEOMETRY NOT NULL. Now Field_*::reset() returns an error sign
and it's checked in mysql_load()

into  neptunus.(none):/home/msvensson/mysql/mysql-4.1-maint

into  neptunus.(none):/home/msvensson/mysql/mysql-4.1-maint

into  rolltop.ignatz42.dyndns.org:/mnt/storeage/mysql-4.1-maint

- Comment Cleanup.

into  rolltop.ignatz42.dyndns.org:/mnt/storeage/mysql-4.1-maint