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

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

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.

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

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

If mysql_lock_tables fails because the lock was aborted, we need to
reset thd->some_tables_delete, otherwise we might loop indefinitely
because handler's tables are not closed in a standard way, meaning
that close_thread_tables() (which resets some_tables_deleted) is not
used.

This patch fixes sporadical failures of handler_myisam/innodb tests
which were introduced by previous fix for this bug.

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

(compiler issue ?)

Problem:

Improper compile-time flags on AIX prevented use of files > 2 GB. This
resulted in Max_data_length being truncated to 2 GB by MyISAM code.

Solution:

Reverted large-file changes from the fix for bug10776. We need to define
_LARGE_FILES on AIX to have support for files > 2 GB.

 Since _LARGE_FILE_API is incompatible with _LARGE_FILES and may be
automatically defined by including standards.h, we also need a
workaround to avoid this conflict.

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

makedate() will fold years below 100 into the 1970-2069 range. CS removes code
that also wrongly folded years between 100 and 200 into that range, which should
be left unchanged. Backport from 5.1.

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

Options to mysqld were not processed correctly because switch statement
was missing some "break"s. CS adds them.

No test case; would require .opt file and server restart. Manually tested.

Problem: GROUP_CONCAT(DISTINCT BIT_FIELD...) uses a tree to store keys;
which are constructed using a temporary table fields,
see Item_func_group_concat::setup().
As a) we don't store null bits in the tree where the bit fields store parts 
of their data and b) there's no method to properly compare two table records
we've got problem.

Fix: convert BIT fields to INT in the temporary table used.

myisam_sort_buffer_size.

An incorrect length of the sort buffer was used when calculating the
maximum number of keys. When myisam_sort_buffer_size is small enough,
this could result in the number of keys < number of
BUFFPEK structures which in turn led to use of uninitialized BUFFPEKs.

Fixed by correcting the buffer length calculation.

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

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

Introduced in mark_transaction_to_rollback(), part of fix for bug 24989;
fix is to check thd for NULL before using it.