- 15 Jun, 2005 20 commits
-
-
hf@deer.(none) authored
into deer.(none):/home/hf/work/mysql-5.0.10632
-
hf@deer.(none) authored
-
hf@deer.(none) authored
into deer.(none):/home/hf/work/mysql-5.0.10337
-
hf@deer.(none) authored
-
georg@lmy002.wdf.sap.corp authored
into lmy002.wdf.sap.corp:/home/georg/work/mysql/prod/mysql-5.0
-
georg@lmy002.wdf.sap.corp authored
-
mskold@mysql.com authored
into mysql.com:/usr/local/home/marty/MySQL/mysql-5.0
-
lenz@mysql.com authored
into mysql.com:/space/my/mysql-5.0
-
mskold@mysql.com authored
into mysql.com:/usr/local/home/marty/MySQL/mysql-5.0
-
igor@rurik.mysql.com authored
Added a teast case for bug #11284. sql_select.cc: Fixed bug #11284. Optimization with empty inner table currently cannot be used in the case of nested outer join.
-
mskold@mysql.com authored
into mysql.com:/usr/local/home/marty/MySQL/mysql-5.0
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/dev/mysql-5.0-0
-
tomas@poseidon.ndb.mysql.com authored
into poseidon.ndb.mysql.com:/home/tomas/mysql-5.0
-
tomas@poseidon.ndb.mysql.com authored
-
igor@rurik.mysql.com authored
Added a test case for bug #11285. sql_select.cc: Fixed bug #11285. The problem occurred with Item_equal in an 'on expression' that was evaluated to false.
-
timour@mysql.com authored
into mysql.com:/home/timka/mysql/src/5.0-dbg
-
mskold@mysql.com authored
into mysql.com:/usr/local/home/marty/MySQL/mysql-5.0
-
georg@lmy002.wdf.sap.corp authored
-
-
timour@mysql.com authored
When the GROUP BY clause contains a column reference that can be resolved to both an aliased column in the SELECT list, and to a column in the FROM clause, the group column is resolved to the column in the FROM clause (for ANSI conformance). However, it may be so that the user's intent is just the other way around, and he/she gets the query results grouped by a completely different column than expexted. This patch adds a warning in such cases that tells the user that there is potential ambiguity in the group column. sql/sql_select.cc - Added a warning when a GROUP column is ambiguous due to that there is a column reference with the same name both in the SELECT and FROM clauses. In this case we resolve to the column in FROM clause and warn the user of a possible ambiguity. - More extensive comments. - Changed the function to return bool instead of int (as in other places). mysql-test/t/group_by.test Added test for BUG#11211. mysql-test/r/group_by.result Added test for BUG#11211.
-
- 14 Jun, 2005 20 commits
-
-
petr@mysql.com authored
into mysql.com:/home/cps/mysql/trees/mysql-5.0
-
bell@sanja.is.com.ua authored
-
lenz@mysql.com authored
into mysql.com:/space/my/mysql-5.0-build
-
bell@sanja.is.com.ua authored
into sanja.is.com.ua:/home/bell/mysql/bk/work-bug3-5.0
-
evgen@moonbone.local authored
into moonbone.local:/work/mysql-5.0-bug-11111
-
evgen@moonbone.local authored
Wrong method for creating temporary field was choosen, which results in sending int field with int header but lonlong data. Test case is added to mysql_client_test.c because client library is required to test the bug.
-
petr@mysql.com authored
-
bell@sanja.is.com.ua authored
-
lenz@mysql.com authored
"--with static" or "--define '_with_static 1'" to the RPM build options. Static linking really only makes sense when linking against the specially patched glibc 2.2.5.
-
hf@deer.(none) authored
-
mskold@mysql.com authored
-
petr@mysql.com authored
-
hf@deer.(none) authored
into deer.(none):/home/hf/work/mysql-5.0.clean
-
hf@deer.(none) authored
-
hf@deer.(none) authored
-
mskold@mysql.com authored
into mysql.com:/usr/local/home/marty/MySQL/mysql-5.0
-
timour@mysql.com authored
into mysql.com:/home/timka/mysql/src/5.0-bug-11044
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0-tmp
-
timour@mysql.com authored
into mysql.com:/home/timka/mysql/src/5.0-bug-11044
-
timour@mysql.com authored
The problem was that when there was no MIN or MAX function, after finding the group prefix based on the DISTINCT or GROUP BY attributes we did not search further for a key in the group that satisfies the equi-join conditions on attributes that follow the group attributes. Thus we ended up with the wrong rows, and subsequent calls to select_cond->val_int() in evaluate_join_record() were filtering those rows. Hence - the query result set was empty. The problem occured both for GROUP BY queries without MIN/MAX and for queries with DISTINCT (which were internally executed as GROUP BY queries).
-