- 12 Feb, 2007 1 commit
-
-
igor@olga.mysql.com authored
The function make_unireg_sortorder ignored the fact that any view field is represented by a 'ref' object. This could lead to wrong results for the queries containing both GROUP BY and ORDER BY clauses.
-
- 11 Feb, 2007 2 commits
-
-
evgen@moonbone.local authored
Post fix for bug#12122. information_schema.result: Corrected test case after fixing bug#12122.
-
evgen@moonbone.local authored
into moonbone.local:/mnt/gentoo64/work/12122-bug-5.0-opt-mysql
-
- 09 Feb, 2007 6 commits
-
-
evgen@moonbone.local authored
present. A view created with CREATE VIEW ... ORDER BY ... cannot be resolved with the MERGE algorithm, even when no other part of the CREATE VIEW statement would require the view to be resolved using the TEMPTABLE algorithm. The check for presence of the ORDER BY clause in the underlying select is removed from the st_lex::can_be_merged() function. The ORDER BY list of the underlying select is appended to the ORDER BY list
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug26017
-
igor@olga.mysql.com authored
Objects of the class Item_equal contain an auxiliary member eval_item of the type cmp_item that is used only for direct evaluation of multiple equalities. Currently a multiple equality is evaluated directly only in the cases when the equality holds at most for one row in the result set. The compare collation of eval_item was determined incorectly. It could lead to returning incorrect results for some queries.
-
evgen@moonbone.local authored
inserted. The select_insert::send_eof() function now resets LAST_INSERT_ID variable if no rows were inserted.
-
gkodinov/kgeorge@macbook.gmz authored
into macbook.gmz:/Users/kgeorge/mysql/work/B22344-5.0-opt
-
gkodinov/kgeorge@macbook.gmz authored
-
- 08 Feb, 2007 3 commits
-
-
gluh@mysql.com/eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.0-opt
-
gluh@mysql.com/eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.0-opt
-
gluh@mysql.com/eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/4.1-opt
-
- 07 Feb, 2007 8 commits
-
-
igor@olga.mysql.com authored
View check option clauses were ignored for updates of multi-table views when the updates could not be performed on fly and the rows to update had to be put into temporary tables first.
-
tomas@poseidon.mysql.com authored
into poseidon.mysql.com:/home/tomas/mysql-4.1-ndb
-
tomas@poseidon.mysql.com authored
into poseidon.mysql.com:/home/tomas/mysql-5.0-ndb
-
mskold/marty@mysql.com/linux.site authored
into mysql.com:/windows/Linux_space/MySQL/mysql-5.0-ndb
-
mskold/marty@mysql.com/linux.site authored
into mysql.com:/windows/Linux_space/MySQL/mysql-5.0-ndb
-
mskold/marty@mysql.com/linux.site authored
bug#25821 Excessive partition pruning for multi-range index scan in NDB API: added multi_range error checking in end_of_bound ha_ndbcluster.h: Removed stray mthod declaration
-
mskold/marty@mysql.com/linux.site authored
bug#25821 Excessive partition pruning for multi-range index scan in NDB API: post-review fix, added default value
-
igor@olga.mysql.com authored
with a column of the DATETIME type could return a wrong result set if the WHERE clause included a BETWEEN condition on the column. Fixed the method Item_func_between::fix_length_and_dec where the aggregation type for BETWEEN predicates calculated incorrectly if the first argument was a view column of the DATETIME type.
-
- 06 Feb, 2007 3 commits
-
-
mskold/marty@mysql.com/linux.site authored
Fix for bug#25821 Excessive partition pruning for multi-range index scan in NDB API: don't set distribution key if multi_range
-
evgen@moonbone.local authored
updated. INSERT ... ON DUPLICATE KEY UPDATE reports that a record was updated when the duplicate key occurs even if the record wasn't actually changed because the update values are the same as those in the record. Now the compare_record() function is used to check whether the record was changed and the update of a record reported only if the record differs from the original one.
-
gkodinov/kgeorge@macbook.gmz authored
Ignoring error codes from type conversion allows default (wrong) values to go unnoticed in the formation of index search conditions. Fixed by correctly checking for conversion errors.
-
- 05 Feb, 2007 1 commit
-
-
- 03 Feb, 2007 2 commits
-
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug24035
-
istruewing@chilla.local authored
-
- 02 Feb, 2007 11 commits
-
-
igor@olga.mysql.com authored
This performance degradation for UPDATEs could be observed in the update statements for which the search key cannot be converted to any valid value of the type of the search column, like for a the condition int_fld=99999999999999999999999999, though it can be guaranteed here that there is no row with such a key value.
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-axmrg
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-axmrg
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-4.1-axmrg
-
istruewing@chilla.local authored
-
gluh@mysql.com/eagle.(none) authored
-
gluh@mysql.com/eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.0-opt
-
gluh@mysql.com/eagle.(none) authored
added valgrind.supp to EXTRA_SCRIPTS(for pushbuild)
-
lzhou/zhl@dev3-63.(none) authored
into dev3-63.(none):/home/zhl/mysql/tree-merge/5.0/mysql-5.0-ndb
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-axmrg
-
istruewing@chilla.local authored
-
- 01 Feb, 2007 3 commits
-
-
lzhou/zhl@dev3-63.(none) authored
into dev3-63.(none):/home/zhl/mysql/tree-merge/5.0/mysql-5.0-ndb
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-axmrg
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-axmrg
-