- 25 Oct, 2007 2 commits
-
-
kaa@polly.(none) authored
-
tsmith@ramayana.hindu.god authored
into ramayana.hindu.god:/home/tsmith/m/bk/maint/50
-
- 24 Oct, 2007 6 commits
-
-
tsmith@ramayana.hindu.god authored
into ramayana.hindu.god:/home/tsmith/m/bk/maint/50
-
ssh://bk-internal.mysql.com//home/bk/mysql-5.0-maintkaa@polly.(none) authored
into polly.(none):/home/kaa/src/maint/mysql-5.0-maint
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/maint/mysql-5.0-maint
-
kaa@polly.(none) authored
some platforms Since the behavior of write(fd, buf, 0) is undefined, it may fail with EFAULT on some architectures when buf == NULL. The error was propagated up to a caller, since my_write() code did not handle it properly. Fixed by checking the 'number of bytes' argument in my_write() and returning before calling the write() system call when there is nothing to write.
-
into mysql.com:/home/ram/work/b31615/b31615.4.1
-
ramil/ram@ramil.myoffice.izhnet.ru authored
into mysql.com:/home/ram/work/b31615/b31615.5.0
-
- 23 Oct, 2007 7 commits
-
-
msvensson@pilot.mysql.com authored
into pilot.mysql.com:/data/msvensson/mysql/mysql-5.0-maint
-
msvensson@pilot.mysql.com authored
into pilot.mysql.com:/data/msvensson/mysql/mysql-5.0-maint
-
ramil/ram@ramil.myoffice.izhnet.ru authored
into mysql.com:/home/ram/work/b31615/b31615.5.0
-
ramil/ram@ramil.myoffice.izhnet.ru authored
into mysql.com:/home/ram/work/b31349/b31349.5.0
-
msvensson@pilot.mysql.com authored
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/maint/mysql-5.0-maint
-
ramil/ram@ramil.myoffice.izhnet.ru authored
into mysql.com:/home/ram/work/b31349/b31349.5.0
-
- 22 Oct, 2007 2 commits
-
-
tsmith@ramayana.hindu.god authored
into ramayana.hindu.god:/home/tsmith/m/bk/maint/50
-
kaa@polly.(none) authored
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.
-
- 19 Oct, 2007 4 commits
-
-
antony@anubis.xiphis.org authored
into anubis.xiphis.org:/usr/home/antony/work/mysql-5.0-engines.merge
-
antony@pcg5ppc.xiphis.org authored
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.
-
- 18 Oct, 2007 4 commits
-
-
malff@lambda.hsd1.co.comcast.net. authored
into lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.0-rt-merge
-
msvensson@pilot.mysql.com authored
into pilot.mysql.com:/data/msvensson/mysql/mysql-5.0-maint
-
msvensson@pilot.mysql.com authored
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/maint/mysql-5.0-maint
-
- 17 Oct, 2007 6 commits
-
-
dkatz@damien-katzs-computer.local authored
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.
-
tsmith@ramayana.hindu.god authored
in middle of block)
-
kaa@polly.(none) authored
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.
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/maint/mysql-5.0-maint
-
kaa@polly.(none) authored
-
- 16 Oct, 2007 6 commits
-
-
malff@lambda.hsd1.co.comcast.net. authored
-
malff@lambda.hsd1.co.comcast.net. authored
into lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.0-28318-rework
-
malff@lambda.hsd1.co.comcast.net. authored
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/maint/mysql-5.0-maint
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/maint/mysql-4.1-maint
-
malff@lambda.hsd1.co.comcast.net. authored
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)
-
- 15 Oct, 2007 3 commits
-
-
dkatz@damien-katzs-computer.local authored
into damien-katzs-computer.local:/Users/dkatz/mysql-5.0-runtime
-
msvensson@pilot.mysql.com authored
into pilot.mysql.com:/data/msvensson/mysql/mysql-5.0-maint
-
kaa@polly.(none) authored
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.
-