An error occurred fetching the project authors.
- 04 May, 2006 1 commit
-
-
jani@ua141d10.elisa.omakaista.fi authored
is only to make sure that this will not be fixed, as it is intended behaviour. Documentation will be improved accordingly.
-
- 01 Apr, 2006 1 commit
-
-
igor@rurik.mysql.com authored
Multiple equalities were not adjusted after reading constant tables. It resulted in neglecting good index based methods that could be used to access of other tables.
-
- 11 Jan, 2006 3 commits
-
-
evgen@moonbone.local authored
Absence of table in left part of LEFT/RIGHT join wasn't checked before name resolution which resulted in NULL dereferencing and server crash. Modified rules: "table_ref LEFT opt_outer JOIN_SYM table_ref" and "table_ref RIGHT opt_outer JOIN_SYM table_ref" NULL check is moved before push_new_name_resolution_context()
-
evgen@moonbone.local authored
functions are involved. When subselect is a join with set functions and no record have been found in it, end_send_group() sets null_row for all tables in order aggregate functions to calculate their values correctly. Normally this null_row flag is cleared for each table in sub_select(), but flush_cached_records() doesn't do so. Due to this all fields from the table processed by flush_cached_records() are always evaluated as nulls and whole select produces wrong result. flush_cached_records() now clears null_row flag at the very beginning.
-
evgen@moonbone.local authored
select result Item equal objects are employed only at the optimize phase. Usually they are not supposed to be evaluated. Yet in some cases we call the method val_int() for them. Here we have to take care of restricting the predicate such an object represents f1=f2= ...=fn to the projection of known fields fi1=...=fik. Added a check for field's table being const in Item_equal::val_int(). If the field's table is not const val_int() just skips that field when evaluating Item_equal.
-
- 09 Dec, 2005 1 commit
-
-
evgen@moonbone.local authored
cmp_item_sort_string::cmp() wasn't checking values_res variable for null. Later called function was dereferenced it and crashed server. Added null check to cmp_item_sort_string::cmp().
-
- 26 Nov, 2005 1 commit
-
-
igor@rurik.mysql.com authored
A typo bug caused loss of a predicate of the form field=const in some cases.
-
- 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.
-
- 11 Nov, 2005 1 commit
-
-
timour@mysql.com authored
the same column as an aliased and as a non-aliased column. The problem was that Item_direct_view_ref::eq() was first comparing view columns by name, and in this case the name of one of them is different since it is aliased.
-
- 03 Nov, 2005 1 commit
-
-
evgen@moonbone.local authored
Invalid date like 2000-02-32 wasn't converted to int, which lead to not using index and comparison with field as astring, which results in slow query execution. convert_constatn_item() and get_mm_leaf() now forces MODE_INVALID_DATES to allow such conversion.
-
- 25 Oct, 2005 1 commit
-
-
timour@mysql.com authored
The cause for the bug is that the priorities of all rules/terminals that process the FROM clause are not fully specified, and the parser generator produces a parser that doesn't always parse the FROM clause so that JOINs are left-associative. As a result the final join tree produced by the parser is incorrect, which is the cause for subsequent name resolution to fail.
-
- 21 Oct, 2005 1 commit
-
-
andrey@lmy004. authored
ESCAPE has length of 1 if specified and sql_mode is NO_BACKSLASH_ESCAPES or has length of 0 or 1 in every other situation. (approved patch applied on a up-to-date tree re-commit)
-
- 13 Oct, 2005 4 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.
-
monty@mysql.com authored
Move handling of suffix_length from strnxfrm_bin() to filesort to ensure proper sorting of all kind of binary objects field::sort_key() now adds length last for varbinary/blob VARBINARY/BLOB is now sorted by filesort so that shorter strings comes before longer ones Fixed issues in test cases from last merge
-
hf@deer.(none) authored
-
hf@deer.(none) authored
-
- 12 Oct, 2005 1 commit
-
-
evgen@moonbone.local authored
Bug #7672 after merge fix
-
- 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().
-
- 30 Sep, 2005 1 commit
-
-
timour@mysql.com authored
Fix for BUG#13597 - columns in ON condition not resolved if references a table in a nested right join. The problem was in that when finding the last table reference in a nested join tree, the procedure doing the iteration over the right-most branches of a join tree was testing for RIGHT JOINs the table reference that represents the join, and not the second operand of the JOIN. Currently the information whether a join is LEFT/RIGHT is stored not on the join object itself, but on one of its operands.
-
- 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.
-
- 20 Sep, 2005 1 commit
-
-
timour@mysql.com authored
The problem was in the way table references are pre-filtered when resolving a qualified field. When resolving qualified table references we search recursively in the operands of the join. If there is natural/using join with a merge view, the first call to find_field_in_table_ref makes a recursive call to itself with the view as the new table reference to search for the column. However the view has both nested_join and join_columns != NULL so it skipped the test whether the view name matches the field qualifier. As a result the field was found in the view since the view already has a field with the same name. Thus the field was incorrectly resolved as the view field.
-
- 15 Sep, 2005 1 commit
-
-
evgen@moonbone.local authored
Optimizer did choose "Range checked for each record" for one of the tables. For first few loops over that table it choose sequential access, on later stage it choose to use index. Because table was previously initialized for sequential access, it skips intitialization for index access, and when server tries to retrieve data error occurs. QUICK_RANGE_SELECT::init() changes so if file already initialized for sequential access, it calls ha_rnd_end() and initializes file for index access.
-
- 12 Sep, 2005 2 commits
-
-
timour@mysql.com authored
-
timour@mysql.com authored
-
- 10 Sep, 2005 1 commit
-
-
timour@mysql.com authored
The problem was that in the first production in rule 'join_table', that processes simple cross joins, the parser was processing the second join operand before the first one due to unspecified priorities of JOINs. As a result in the case of cross joins the parser constructed a tree with incorrect nesting: the expression "t1 join t2 join t3 on some_cond" was interpreted as "t1 join (t2 join t3 on some_cond)" instead of "(t1 join t2) join t3 on some_cond". Because of this incorrect nesting the method make_join_on_context picked an incorrect table as the first table of the name resolution context. The solution assignes correct priorities to the related production.
-
- 08 Sep, 2005 1 commit
-
-
timour@mysql.com authored
-
- 29 Aug, 2005 1 commit
-
-
andrey@lmy004. authored
(Server crash on DO IFNULL(NULL,NULL) (fixes also "SELECT CAST(IFNULL(NULL,NULL) as DECIMAL)" unreported crash) (new revampled fix with suggestions from Igor)
-
- 23 Aug, 2005 5 commits
-
-
timour@mysql.com authored
The bug itself is fixed by WL#2486.
-
timour@mysql.com authored
due to incorrect transformation to JOIN ... ON. The bug itself is fixed by WL#2486.
-
timour@mysql.com authored
-
timour@mysql.com authored
The bug itself is fixed by WL#2486.
-
timour@mysql.com authored
* Provide backwards compatibility extension to name resolution of coalesced columns. The patch allows such columns to be qualified with a table (and db) name, as it is in 4.1. Based on a patch from Monty. * Adjusted tests accordingly to test both backwards compatible name resolution of qualified columns, and ANSI-style resolution of non-qualified columns. For this, each affected test has two versions - one with qualified columns, and one without.
-
- 22 Aug, 2005 2 commits
-
-
timour@mysql.com authored
The bug itself is fixed by WL #2486.
-
timour@mysql.com authored
The bug is non-view specific, and it resulted from incorrect name resolution of natural join result columns. The bug is fixed by WL#2486.
-
- 18 Aug, 2005 1 commit
-
-
jimw@mysql.com authored
-
- 17 Aug, 2005 1 commit
-
-
timour@mysql.com authored
- fixed a problem with RIGHT JOIN ON and enabled corresponding tests in select.test - fixed a memory leak
-
- 16 Aug, 2005 2 commits
-
-
evgen@moonbone.local authored
When copying varchar fields with field_conv() it's not taken into account that length_bytes of source and destination fields may be different. This results in saving wrong data in field and making wrong key later. Added check so if fields are varchar and have different length_bytes they are not copied by memcpy().
-
andrey@lmy004. authored
-