- 18 Jul, 2006 8 commits
-
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-5.0-opt-mysql
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-5.0-opt-mysql
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-4.1-opt-mysql
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-5.0-opt-mysql
-
into production.mysql.com:/usersnfs/abotchkov/mysql-5.0.mrg
-
holyfoot/hf@mysql.com/deer.(none) authored
-
holyfoot/hf@mysql.com/deer.(none) authored
into mysql.com:/home/hf/work/mysql-5.0.mrg
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
-
- 17 Jul, 2006 7 commits
-
-
igor@rurik.mysql.com authored
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/mysql-5.0-opt
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/mysql-5.0-opt
-
evgen@moonbone.local authored
Test case for bug#10977 altered to make it work in both plain and ps-protocol modes.
-
evgen@moonbone.local authored
Corrected the test case after fixing bug#10977
-
msvensson@shellback.(none) authored
into shellback.(none):/home/msvensson/mysql/mysql-5.0-maint
-
msvensson@shellback.(none) authored
- Fix for "bug#16755 Please find a SSL library that is FLOSS-Exception / LGPL copyrighted"
-
- 16 Jul, 2006 1 commit
-
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/mysql-5.0-opt
-
- 15 Jul, 2006 5 commits
-
-
evgen@moonbone.local authored
Fixed bug#10977: No warning issued if a column name is truncated New warning message is added.
-
evgen@moonbone.local authored
When an alias is set to a column leading spaces are removed from the alias. But when this is done on aliases set by user this can lead to confusion. Now Item::set_name() method issues the warning if leading spaces were removed from an alias set by user. New warning message is added.
-
pekka@orca.ndb.mysql.com authored
into orca.ndb.mysql.com:/space_old/pekka/ndb/version/my50
-
igor@rurik.mysql.com authored
The bug caused a crash of the server if a subquery with ORDER BY DESC used the range access method. The bug happened because the method QUICK_SELECT_DESC::reset was not reworked after MRR interface had been introduced.
-
igor@olga.mysql.com authored
The bug was due to a loss happened during a refactoring made on May 30 2005 that modified the function JOIN::reinit. As a result of it for any subquery the value of offset_limit_cnt was not restored for the following executions. Yet the first execution of the subquery made it equal to 0. The fix restores this value in the function JOIN::reinit.
-
- 14 Jul, 2006 9 commits
-
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/mysql-5.0-opt
-
-
into anubis.greendragongames.com:/home/greenman/workspace-mysql/mysql/merge-4.1_2_5.0
-
-
gkodinov/kgeorge@rakia.(none) authored
into rakia.(none):/home/kgeorge/mysql/autopush/B17212-4.1-opt
-
gkodinov/kgeorge@macbook.gmz authored
Discussed with Kent.
-
gkodinov/kgeorge@macbook.gmz authored
into macbook.gmz:/Users/kgeorge/mysql/work/B17212-5.0-opt
-
igor@olga.mysql.com authored
-
igor@olga.mysql.com authored
DESCRIBE returned the type BIGINT for a column of a view if the column was specified by an expression over values of the type INT. E.g. for the view defined as follows: CREATE VIEW v1 SELECT COALESCE(f1,f2) FROM t1 DESCRIBE returned type BIGINT for the only column of the view if f1,f2 are columns of the INT type. At the same time DESCRIBE returned type INT for the only column of the table defined by the statement: CREATE TABLE t2 SELECT COALESCE(f1,f2) FROM t1. This inconsistency was removed by the patch. Now the code chooses between INT/BIGINT depending on the precision of the aggregated column type. Thus both DESCRIBE commands above returns type INT for v1 and t2.
-
- 13 Jul, 2006 10 commits
-
-
-
into mysql.com:/home/tnurnberg/work/mysql-5.0-21014
-
mysqldump did not select the correct database before trying to dump views from it. this resulted in an empty result set, which in turn startled mysql-dump into a core-dump. this only happened for views, not for tables, and was only visible with multiple databases that weren't by sheer luck in the order mysqldump required, anyway. this fixes by selecting the correct database before dumping views; it also catches the empty set-condition if it should occur for other reasons.
-
holyfoot/hf@mysql.com/deer.(none) authored
into mysql.com:/home/hf/work/mysql-4.1.16017
-
cmiller@zippy.(none) authored
into zippy.(none):/home/cmiller/work/mysql/m41-maint--07AB5
-
cmiller@zippy.(none) authored
into zippy.(none):/home/cmiller/work/mysql/m41-maint--07AB5
-
cmiller@zippy.(none) authored
into zippy.(none):/home/cmiller/work/mysql/m50--07C2P
-
cmiller@zippy.(none) authored
into zippy.(none):/home/cmiller/work/mysql/m50-maint--07C2P
-
cmiller@zippy.(none) authored
into zippy.(none):/home/cmiller/work/mysql/m50-maint--07C2P
-
iggy@rolltop.ignatz42.dyndns.org authored
-