into  mysql.com:/home/ram/work/b31615/b31615.5.0

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

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

into  mysql.com:/home/ram/work/b31615/b31615.5.0

into  mysql.com:/home/ram/work/b31349/b31349.5.0

into  polly.(none):/home/kaa/src/maint/mysql-5.0-maint

into  mysql.com:/home/ram/work/b31349/b31349.5.0

into  ramayana.hindu.god:/home/tsmith/m/bk/maint/50

Fixed the Windows build failures introduced by the patch for bug #31207: Test "join_nested" shows different strategy on IA64 CPUs / Intel's ICC compiler.

into  anubis.xiphis.org:/usr/home/antony/work/mysql-5.0-engines.merge

into  anubis.xiphis.org:/usr/home/antony/work/mysql-5.0-engines.merge

into  anubis.xiphis.org:/usr/home/antony/work/mysql-4.1-engines.merge

Problem: lying to the optimizer that a function (Item_func_inet_ntoa)
cannot return NULL values leads to unexpected results (in the case group
keys creation/comparison is broken). 

Fix: Item_func_inet_ntoa::maybe_null should be set properly.

into  lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.0-rt-merge

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

into  polly.(none):/home/kaa/src/maint/mysql-5.0-maint

    
Previously, UDF *_init functions were passed constant strings with erroneous lengths. The length came from the containing variable's size, not the length of the value itself.
    
Now the *_init functions get the constant as a null terminated string with the correct length supplied too.

in middle of block)

CPUs / Intel's ICC compile

The bug is a combination of two problems:

1. IA64/ICC MySQL binaries use glibc's qsort(), not the one in mysys.

2. The order relation implemented by join_tab_cmp() is not transitive,
i.e. it is possible to choose such a, b and c that (a < b) && (b < c)
but (c < a). This implies that result of a sort using the relation
implemented by join_tab_cmp() depends on the order in which
elements are compared, i.e. the result is implementation-specific. Since
choose_plan() uses qsort() to pre-sort the
join tables using join_tab_cmp() as a compare function, the results of
the sorting may vary depending on qsort() implementation.

It is neither possible nor important to implement a better ordering
algorithm in join_tab_cmp(). Therefore the only way to fix it is to
force our own qsort() to be used by renaming it to my_qsort(), so we don't depend
on linker to decide that.

This patch also "fixes" bug #20530: qsort redefinition violates the
standard.

Problem: currently, UCS-2 cannot be used as a client character set.

Fix: raise an error if one attempts to set it to USC-2.

into  polly.(none):/home/kaa/src/maint/mysql-5.0-maint

into  lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.0-28318-rework

into  polly.(none):/home/kaa/src/maint/mysql-5.0-maint

into  polly.(none):/home/kaa/src/maint/mysql-4.1-maint

The root cause of the issue was that the CREATE FUNCTION grammar,
for User Defined Functions, was using the sp_name rule.
The sp_name rule is intended for fully qualified stored procedure names,
like either ident.ident, or just ident but with a default database
implicitly selected.

A UDF does not have a fully qualified name, only a name (ident), and should
not use the sp_name grammar fragment during parsing.

The fix is to re-organize the CREATE FUNCTION grammar, to better separate:
- creating UDF (no definer, can have AGGREGATE, simple ident)
- creating Stored Functions (definer, no AGGREGATE, fully qualified name)

With the test case provided, another issue was exposed which is also fixed:
the DROP FUNCTION statement was using sp_name and also failing when no database
is implicitly selected, when droping UDF functions.
The fix is also to change the grammar so that DROP FUNCTION works with
both the ident.ident syntax (to drop a stored function), or just the ident
syntax (to drop either a UDF or a Stored Function, in the current database)

into  damien-katzs-computer.local:/Users/dkatz/mysql-5.0-runtime

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

Problem:

my_strntoull10rnd_8bit() handled incorrectly cases when the input
string contains a decimal point and is long enough to overrun the
'unsigned long long' type. The position of the decimal point was not
taken into account which resulted in miscalculated numbers and
truncation to appropriate SQL data type limits.

Solution:

Fix my_strntoull10rnd_8bit() to take the position of a decimal point
into account in such cases.

into  mysql.com:/home/ram/work/b31154/b31154.5.0

into  mysql.com:/home/ram/work/b31154/b31154.5.0

into  mysql.com:/home/ram/work/b30885/b30885.5.0

into  solace.(none):/home/mtaylor/src/mysql/mysql-5.0-maint

into  sin.intern.azundris.com:/home/tnurnberg/30951/50-30951

into  moksha.com.br:/Users/davi/mysql/mysql-5.0-runtime