into  mysql.com:/scratch/tnurnberg/20901/51-20901

CREATE TABLE IF NOT EXISTS ... SELECT let you insert into an existing
table as long as you had the CREATE privilege.  CREATE ... SELECT
variants now always require INSERT privilege on target table.

into  mysql.com:/scratch/tnurnberg/20901/50-20901

CREATE TABLE IF NOT EXISTS ... SELECT let you insert into an existing
table as long as you had the CREATE privilege.  CREATE ... SELECT
variants now always require INSERT privilege on target table.

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

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.

Post-merge changes for bug #31207: Test "join_nested" shows different strategy on IA64 CPUs / Intel's ICC compiler.

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

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

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

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.1-maint

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

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

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

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

into  pilot.mysql.com:/data/msvensson/mysql/mysql-5.1-new-maint

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

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

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/b31154/b31154.5.1

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

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

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

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

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

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

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

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

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

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

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

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

into  polly.(none):/home/kaa/src/maint/bug31254/my51-bug31254

(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/51-30951