An error occurred fetching the project authors.
- 07 Nov, 2007 1 commit
-
-
kaa@polly.(none) authored
variable in where clause. Problem: the new_item() method of Item_uint used an incorrect constructor. "new Item_uint(name, max_length)" calls Item_uint::Item_uint(const char *str_arg, uint length) which assumes the first argument to be the string representation of the value, not the item's name. This could result in either a server crash or incorrect results depending on usage scenarios. Fixed by using the correct constructor in new_item(): Item_uint::Item_uint(const char *str_arg, longlong i, uint length).
-
- 06 Dec, 2006 1 commit
-
-
Problem: storing >=8 byte hexadecimal values we don't check data. Fix: check if the data fits the {u}longlong range.
-
- 26 Jul, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
When optimizing conditions like 'a = <some_val> OR a IS NULL' so that they're united into a single condition on the key and checked together the server must check which value is the NULL value in a correct way : not only using ->is_null but also check if the expression doesn't depend on any tables referenced in the current statement. This additional check must be performed because that optimization takes place before the actual execution of the statement, so if the field was initialized to NULL from a previous statement the optimization would be applied incorrectly.
-
- 25 Jul, 2006 1 commit
-
-
timour/timka@lamia.home authored
The problem was in that opt_sum_query() replaced MIN/MAX functions with the corresponding constant found in a key, but due to imprecise representation of float numbers, when evaluating the where clause, this comparison failed. When MIN/MAX optimization detects that all tables can be removed, also remove all conjuncts in a where clause that refer to these tables. As a result of this fix, these conditions are not evaluated twice, and in the case of float number comparisons we do not discard result rows due to imprecise float representation. As a side-effect this fix also corrects an unnoticed problem in bug 12882.
-
- 20 Jun, 2006 1 commit
-
-
evgen@moonbone.local authored
Added test case for bug#18759 Incorrect string to numeric conversion. select.test: Added test case for bug#18759 Incorrect string to numeric conversion. item_cmpfunc.cc: Cleanup after fix for bug#18360 removal
-
- 02 Jun, 2006 1 commit
-
-
gkodinov@mysql.com authored
3.23 regression test failure The member SEL_ARG::min_flag was not initialized, due to which the condition for no GEOM_FLAG in function key_or did not choose "Range checked for each record" as the correct access method.
-
- 30 May, 2006 1 commit
-
-
igor@rurik.mysql.com authored
refers to a column name.
-
- 28 May, 2006 1 commit
-
-
igor@rurik.mysql.com authored
refers to a column name. Added a new error message ER_INDEX_DOES_NOT_EXIST.
-
- 24 Nov, 2005 1 commit
-
-
evgen@moonbone.local authored
crash resolve_const_item() substitutes item which will evaluate to constant with equvalent constant item, basing on the item's result type. In this case subselect was resolved as constant, and resolve_const_item() was substituting it's result's Item_caches to Item_null. Later Item_cache's function was called for Item_null object, which caused server crash. resolve_const_item() now substitutes constants for items with result_type == ROW_RESULT only for Item_rows.
-
- 27 Oct, 2005 1 commit
-
-
evgen@moonbone.local authored
After merge fix
-
- 13 Oct, 2005 3 commits
-
-
evgen@moonbone.local authored
DISTINCT wasn't optimized away and caused creation of tmp table in wrong case. This result in integer overrun and running out of memory. Fix backported from 4.1. Now if optimizer founds that in result be only 1 row it removes distinct.
-
hf@deer.(none) authored
-
hf@deer.(none) authored
-
- 09 Oct, 2005 1 commit
-
-
evgen@moonbone.local authored
When fixing Item_func_plus in ORDER BY clause field c is searched in all opened tables, but because c is an alias it wasn't found there. This patch adds a flag to select_lex which allows Item_field::fix_fields() to look up in select's item_list to find aliased fields.
-
- 07 Oct, 2005 1 commit
-
-
monty@mysql.com authored
- Use %lx instead of %p as %p is not portable - Don't replace ROW item with Item_null
-
- 03 Oct, 2005 1 commit
-
-
evgen@moonbone.local authored
After SHOW TABLE STATUS last_insert_id wasn't cleaned, and next select erroneously rewrites WHERE condition and returs a row; 5.0 isn't affected because of different SHOW TABLE STATUS handling. last_insert_id cleanup added to mysqld_extend_show_tables().
-
- 27 Sep, 2005 1 commit
-
-
evgen@moonbone.local authored
resolve_const_item() assumed to be not called for Item_row items. For ensuring that DBUG_ASSERT(0) was set there. This patch adds section for Item_row items. If it can it recursively calls resolve_const_item() for each item the Item_row contains. If any of the contained items is null then whole Item_row substitued by Item_null. Otherwise it just returns.
-
- 19 Jul, 2005 1 commit
-
-
monty@mishka.local authored
-
- 17 Jul, 2005 1 commit
-
-
igor@rurik.mysql.com authored
Added a test case for bug #11745. sql_select.cc: Fixed bug # 11745. Added support of where clause for queries with FROM DUAL. sql_yacc.yy: Fixed bug # 11745. Added optional where clause for queries with FROM DUAL.
-
- 16 Jul, 2005 1 commit
-
-
timour@mysql.com authored
"Negative integer keys incorrectly substituted for 0 during range analysis." The problem is that the range optimizer incorrectly replaces any negative constant with '0' for all types except BIGINT because the method save_in_field() casts negative integers to non-negative. This causes incorrect query results where (0 = any_negative_number). The problem caused by this bug is fixed by the patch for BUG#11185. That patch constitutes an optimization due to which the problem code is never called with negative constants. This patch adds a test so we are sure that the problem does not reappear.
-
- 15 Jul, 2005 1 commit
-
-
evgen@moonbone.local authored
than in previous 4.1.x Wrongly applied optimization were adding NOT NULL constraint which results in rejecting valid rows and reduced result set. The problem was that add_notnull_conds() while checking subquery were adding NOT NULL constraint to left joined table, to which, normally, optimization don't have to be applied.
-
- 14 Jul, 2005 1 commit
-
-
sergefp@mysql.com authored
This is needed because in some cases range optimization is performed twice and added NOT NULL item must have correct const_table_map() value.
-
- 28 Jun, 2005 1 commit
-
-
bell@sanja.is.com.ua authored
(IN() remove NULL rows only for tables from first argument (value which we looking for in IN() list) but not for tables from IN() list) Also it will be better change Item::not_null_tables() to prohibit this optimisation by default for new created items in 5.0 or 5.1.
-
- 24 May, 2005 1 commit
-
-
jani@ua141d10.elisa.omakaista.fi authored
-
- 19 May, 2005 1 commit
-
-
serg@serg.mylan authored
-
- 15 May, 2005 1 commit
-
-
sergefp@mysql.com authored
The problem: base_list::remove didn't modify base_list::last when removing the last list element. The fix: If we remove the last element, find the element before it (by walking from the beginning of the list) and set base_list::last accordingly. The list gets corrupted in both 4.0 and 4.1. There are no visible problems in current 4.1 because current 4.1 doesn't call where_cond->fix_fields() after constant propagation step.
-
- 13 May, 2005 1 commit
-
-
monty@mysql.com authored
-
- 09 May, 2005 1 commit
-
-
antony@ltantony.mysql.com authored
Detect conflicting options in SELECT
-
- 31 Mar, 2005 1 commit
-
-
jimw@mysql.com authored
up a couple of tests and adjusting the output of others. Exposes two bugs (9472 and 9508).
-
- 09 Mar, 2005 1 commit
-
-
timour@mysql.com authored
The reported problems were due to two completely unrelated omissions. 1) The file sort procedure didn't correctly create the sort key in make_sortkey when the sortkey was an unsigned integer. 2) The name resolution procedure for column references inside a HAVING clause did not propagate the unsigned_flag of the resolved references. This patch corrects both problems.
-
- 17 Feb, 2005 1 commit
-
-
igor@rurik.mysql.com authored
Added a test case for bug #7098. sql_select.cc: Fixed bug #7098. When a string field was substituted for an equal constant the collation of the constant was changed by mistake for the binary collation.
-
- 11 Feb, 2005 3 commits
-
-
igor@rurik.mysql.com authored
After revision of the fix for bug #7520. table.cc: Revised the fix for bug #7520. Made it compliant with 5.0 code where the bug does not exist.
-
igor@rurik.mysql.com authored
Adjusted results of the test case for bug #7520 for 4.1.
-
igor@rurik.mysql.com authored
Added a test case for bug #7520. table.cc: Fixed bug #7520. The bug was caused by a wrong calculation of the field max_key_length for a TABLE structure when there was an index on a blob field.
-
- 28 Nov, 2004 1 commit
-
-
serg@serg.mylan authored
-
- 26 Nov, 2004 1 commit
-
-
monty@mysql.com authored
(Cleanups and better bug fixes)
-
- 16 Nov, 2004 1 commit
-
-
ram@gw.mysql.r18.ru authored
-
- 07 Oct, 2004 1 commit
-
-
monty@mysql.com authored
Some bigger code changes was necessary becasue of the multi-table-update and the new HANDLER code
-
- 07 Sep, 2004 1 commit
-
-
serg@serg.mylan authored
-
- 03 Sep, 2004 1 commit
-
-
igor@rurik.mysql.com authored
Added a test case for bug #5333. null_key.result, key_primary.result: Made covering index usable for const tables. sql_select.cc: Made covering index usable for const tables: downported the corresponding code from 4.1. Simultaneously fixed bug #5333 reported for 4.1. The bug was due to the fact that field index in join structures was always set to 0 for const tables.
-