- 24 Jan, 2007 3 commits
-
-
gkodinov/kgeorge@macbook.gmz authored
into macbook.gmz:/Users/kgeorge/mysql/work/merge-5.1-opt
-
gkodinov/kgeorge@macbook.gmz authored
-
holyfoot/hf@mysql.com/hfmain.(none) authored
geometry dependent parts moved to proper .test files
-
- 23 Jan, 2007 3 commits
-
-
gkodinov/kgeorge@rakia.gmz authored
into rakia.gmz:/home/kgeorge/mysql/autopush/B6172-5.1-opt
-
gkodinov/kgeorge@macbook.gmz authored
RAND() must accept scalar expressions regardless of their kind. That includes both constant expressions and expressions that depend on column values. When the expression is constant the random seed can be initialized at compile time. However when the expression is not constant the random seed must be initialized at each invocation (while it still can be allocated at compile time). Implemented the above rules by extending Item_func_rand::val_real() to initialize the random seed at the correct place.
-
gkodinov/kgeorge@macbook.gmz authored
into macbook.gmz:/Users/kgeorge/mysql/work/merge-5.1-opt
-
- 22 Jan, 2007 5 commits
-
-
evgen@moonbone.local authored
Code cleanup after fix for bug#23417.
-
evgen@moonbone.local authored
Post fix for bug#25123.
-
evgen@moonbone.local authored
When inserting into a join-based view the update fields from the ON DUPLICATE KEY UPDATE wasn't checked to be from the table being inserted into and were silently ignored. The new check_view_single_update() function is added to check that insert/update fields are being from the same single table of the view.
-
gkodinov/kgeorge@rakia.gmz authored
into rakia.gmz:/home/kgeorge/mysql/autopush/B16590-5.1-opt
-
gkodinov/kgeorge@macbook.gmz authored
st_table::const_key_parts member is used in determining if certain key has a prefix that is compared to constant(s) in the query predicates. If there's such prefix the index can be used to get the data from the remaining suffix columns in sorted order. However if a field is compared to another field from a "const" table the const_key_parts is not amended. This makes the optimizer unable to detect that the key can be used for sorting and adds an extra filesort. Fixed by updating const_key_parts after reading in the "const" table.
-
- 19 Jan, 2007 6 commits
-
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug25580
-
evgen@moonbone.local authored
into moonbone.local:/work/25172-bug-5.0-opt-mysql
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug25580
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug25580
-
evgen@moonbone.local authored
After fix for bug#21798 JOIN stores the pointer to the buffer for sorting fields. It is used while sorting for grouping and for ordering. If ORDER BY clause has more elements then the GROUP BY clause then a memory overrun occurs. Now the length of the ORDER BY list is always passed to the make_unireg_sortorder() function and it allocates buffer big enough to be used for bigger list.
-
igor@olga.mysql.com authored
UNION over correlated and uncorrelated SELECTS. In such subqueries each uncorrelated SELECT should be considered as uncacheable. Otherwise join_free is called for it and in many cases it causes some problems.
-
- 18 Jan, 2007 3 commits
-
-
gkodinov/kgeorge@rakia.gmz authored
into rakia.gmz:/home/kgeorge/mysql/autopush/B25382-5.0-opt
-
gkodinov/kgeorge@macbook.gmz authored
crashes server Check for null value is reliable only after calling some of the val_xxx() methods. If the val_xxx() method is not called the null_value flag will be set only for certain types of NULL values (like SQL constant NULLs for example). This caused a crash while trying to dereference a NULL pointer that is returned by val_str() for NULL values. Fixed by swapping the order of val_xxx() and null_value check.
-
igor@olga.mysql.com authored
when they contain the '!' operator. Added an implementation for the method Item_func_not::print. The method encloses any NOT expression into extra parentheses to avoid incorrect stored representations of views that use the '!' operators. Without this change when a view was created that contained the expression !0*5 its stored representation contained not this expression but rather the expression not(0)*5 . The operator '!' is of a higher precedence than '*', while NOT is of a lower precedence than '*'. That's why the expression !0*5 is interpreted as not(0)*5, while the expression not(0)*5 is interpreted as not((0)*5) unless sql_mode is set to HIGH_NOT_PRECEDENCE. Now we translate !0*5 into (not(0))*5.
-
- 15 Jan, 2007 8 commits
-
-
igor@olga.mysql.com authored
-
igor@olga.mysql.com authored
into olga.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
Fix for crashes on 64bit platforms after fixing bug#23417.
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/mysql-5.0-opt
-
gkodinov/kgeorge@rakia.gmz authored
into rakia.gmz:/home/kgeorge/mysql/autopush/B20420-5.0-opt
-
gkodinov/kgeorge@macbook.gmz authored
The optimizer needs to evaluate whether predicates are better evaluated using an index. IN is one such predicate. To qualify an IN predicate must involve a field of the index on the left and constant arguments on the right. However whether an expression is a constant can be determined only by knowing the preceding tables in the join order. Assuming that only IN predicates with expressions on the right that are constant for the whole query qualify limits the scope of possible optimizations of the IN predicate (more specifically it doesn't allow the "Range checked for each record" optimization for such an IN predicate. Fixed by not pre-determining the optimizability of the IN predicate in the case when all right IN operands are not SQL constant expressions
-
gluh@mysql.com/eagle.(none) authored
added new field 'REFERENCED_TABLE_NAME' to 'referential_constraints' table field 'UNIQUE_CONSTRAINT_NAME' contains the name of the referenced index
-
- 14 Jan, 2007 1 commit
-
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/my51-24186
-
- 13 Jan, 2007 1 commit
-
-
igor@olga.mysql.com authored
for queries using 'range checked for each record'. The problem was fixed in 5.0 by the patch for bug 12291. This patch down-ported the corresponding code from 5.0 into QUICK_SELECT::init() and added a new test case.
-
- 12 Jan, 2007 10 commits
-
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/mysql-5.0-opt
-
igor@olga.mysql.com authored
in a select list. The objects of the Item_trigger_field class inherited the implementations of the methods copy_or_same, get_tmp_table_item and get_tmp_table_field from the class Item_field while they rather should have used the default implementations defined for the base class Item. It could cause catastrophic problems for triggers that used SELECTs with select list containing trigger fields such as NEW.<table column> under DISTINCT.
-
evgen@moonbone.local authored
After merge fix
-
evgen@moonbone.local authored
into moonbone.local:/work/latest-5.0-opt-mysql
-
holyfoot/hf@mysql.com/deer.(none) authored
Subselect's engine checks table->status field to determine if the record was properly found when we use keyread upon the table. Partition engine checks all the partitions for given key before return. So if matching record was found in the first partition and no matching records were found in the second, we have table->status == NOT_FOUND after the function, what makes subselects to skip matching records. The patch adds table->status= 0 if we actually found something.
-
gluh@eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.1-opt
-
gluh@eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.1-opt
-
gluh@eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.1-opt
-
gluh@mysql.com/eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.0
-
gluh@mysql.com/eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.0
-