into  mysql.com:/nfsdisk1/lars/MERGE/mysql-4.1-merge

Operating with the prepared statements we don't alloc MYSQL_DATA structure,
but use MYSQL_STMT's field instead (to increase performance by reducing
malloc calls).
So we shouldn't free this structure as we did before.

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.

into  mysql.com:/nfsdisk1/lars/MERGE/mysql-4.1-merge

by the patch for Bug#4968

into  bodhi.local:/opt/local/work/mysql-4.1-4968-to-push

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. 

into  bodhi.local:/opt/local/work/mysql-4.1-runtime

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

into  mysql.com:/nfsdisk1/lars/MERGE/mysql-4.1-merge

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

into  bodhi.local:/opt/local/work/mysql-4.1-runtime

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.

  Reverted change for bug#13859, applied smaller patch from Marko

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

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

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.

no future build of it will include Berkeley DB:
Remove it from the Windows VC++ project files.

into  kpdesk.mysql.com:/home/thek/dev/mysql-4.1-build

into  kpdesk.mysql.com:/home/thek/dev/bug23010/my41-fix23010

into  moonlight.home:/home/tomash/src/mysql_ab/mysql-4.1-bug23443

into  moonlight.home:/home/tomash/src/mysql_ab/mysql-4.1-bug23443

           server

The problem was that when memory was exhausted HEAP engine could crash
(GROUP BY uses HEAP TABLE).  Alternatively, if SET was used, it could
report an error "You may only use constant expressions with SET" instead
of "Out of memory (Needed NNNNNN bytes)".

The solution is:
 - pass MY_WME to (some) calls to my_malloc() to get correct message.
 - fix heap_write() so that the first key is skipped during cleanup
   on ENOMEM because it wasn't inserted and doesn't have to be
   deleted.

No test case is provided because we can't test out-of-memory behaviour
in our current test framework.

- "make_binary_distribution" accepts a dummy "--platform=" argument.

- "MySQL-shared-compat.spec" uses a "version40" define symbol internally.

  Add CFLAGS to gcc call with --print-libgcc-file, to make sure the
  correct "libgcc.a" path is returned for the 32/64 bit architecture

  Patch from Alfredo for TARGET_FAT_BINARY

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

  Renamed hash_create() not to clash with imap using embedded server (bug#13859)