An error occurred fetching the project authors.
- 04 May, 2011 1 commit
-
-
Igor Babaev authored
The bug was introduced by the patch that fixed bug 717577.
-
- 02 Apr, 2011 1 commit
-
-
Sergey Petrunya authored
- "Using MRR" is no longer shown with range access. - Instead, both range and BKA accesses will show one of the following: = "Rowid-ordered scan" = "Key-ordered scan" = "Key-ordered Rowid-ordered scan" depending on whether DS-MRR implementation will do scan keys in order, rowids in order, or both. - The patch also introduces a way for other storage engines/MRR implementations to pass information to EXPLAIN output about the properties of employed MRR scans.
-
- 26 Jan, 2011 1 commit
-
-
Igor Babaev authored
The bug was in the code of the patch fixing bug 698882. With improper casting the method store_key_field::change_source_field was called for the elements of the array TABLE_REF::key_copy that were either of a different type or not allocated at all. This caused crashes in some queries.
-
- 16 Jan, 2011 1 commit
-
-
Igor Babaev authored
-
- 15 Jan, 2011 2 commits
-
-
Igor Babaev authored
Made sure that the optimal fields are used by TABLE_REF objects when building index access keys to joined tables. Fixed a bug in the template function that sorts the elements of a list using the bubble sort algorithm. The bug caused poor performance of the function. Also added an optimization that skips comparison with the most heavy elements that has been already properly placed in the list. Made the comparison of the fields belonging to the same Item_equal more granular: fields belonging to the same table are also ordered according to some rules.
-
Igor Babaev authored
An assertion failure was triggered for a 6-way join query that used two join buffers. The failure happened because every call of JOIN_CACHE::join_matching_records saved and restored status of all tables that were accessed before the table join_tab. It must do it only for those of them that follow the last table using a join buffer.
-
- 18 Oct, 2010 1 commit
-
-
Igor Babaev authored
about the employed join algorithms. Refactored constructors of the JOIN_CACHE* classes.
-
- 13 Oct, 2010 1 commit
-
-
Sergey Petrunya authored
- post-merge fixes
-
- 28 Sep, 2010 1 commit
-
-
Igor Babaev authored
Applied the fix for bug #47217 from the mysql-6.0 codebase. The patch adds not null predicates generated for the left parts of the equality predicates used for ref accesses. This is done for such predicates both in where conditions and on conditions. For the where conditions the not null predicates were generated but in 5.0/5.1 they actually never were used due to some lame merge from 4.1 to 5.0. The fix for bug #47217 made these predicates to be used in the condition pushed to the tables. Yet only this patch generates not null predicates for equality predicated from on conditions of outer joins. This patch introduces a performance regression that can be observed on a test case from null_key.test. The regression will disappear after the fix for bug #57024 from mariadb-5.1 is pulled into mariadb-5.3. The patch contains many changes in the outputs of the EXPLAIN commands since generated not null predicates are considered as parts of the conditions pushed to join tables and may add 'Usingwhere' in some rows of EXPLAINs where there used to be no such comments.
-
- 15 Sep, 2010 1 commit
-
-
Sergey Petrunya authored
- First part of the fix: enable Early NULLs filtering to work when WHERE clause is present
-
- 16 Feb, 2010 1 commit
-
-
Igor Babaev authored
This is the base patch for the task.
-
- 03 Feb, 2010 3 commits
-
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2818.1.26 > revision-id: joro@sun.com-20091109140946-07wao5od7l1vn4x1 > parent: joro@sun.com-20091110082141-ldr8p6s1joczve2j > committer: Georgi Kodinov <joro@sun.com> > branch nick: B48458-5.0-bugteam > timestamp: Mon 2009-11-09 16:09:46 +0200 > message: > Bug #48458: simple query tries to allocate enormous amount of > memory > > The server was doing a bad class typecast causing setting of > wrong value for the maximum number of items in an internal > structure used in equality propagation. > Fixed by not doing the wrong typecast and asserting the type > of the Item where it should be done.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2818.1.13 > revision-id: joro@sun.com-20091030131543-2b23fnqckgbzvete > parent: joro@sun.com-20091030094044-quadg0bwjy7cwqzw > committer: Georgi Kodinov <joro@sun.com> > branch nick: B48291-5.0-bugteam > timestamp: Fri 2009-10-30 15:15:43 +0200 > message: > Bug #48291 : crash with row() operator,select into @var, and > subquery returning multiple rows > > Error handling was missing when handling subqueires in WHERE > and when assigning a SELECT result to a @variable. > This caused crash(es). > > Fixed by adding error handling code to both the WHERE > condition evaluation and to assignment to an @variable.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2818.1.4 > revision-id: ramil@mysql.com-20091021090408-208mvwwrcroi2j8c > parent: azundris@mysql.com-20091021033856-ydodp4q42o58e7ka > committer: Ramil Kalimullin <ramil@mysql.com> > branch nick: b47019-5.0-bugteam > timestamp: Wed 2009-10-21 14:04:08 +0500 > message: > Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, > line 138 when forcing a spatial index > > Problem: "Spatial indexes can be involved in the search > for queries that use a function such as MBRContains() > or MBRWithin() in the WHERE clause". > Using spatial indexes for JOINs with =, <=> etc. > predicates is incorrect. > > Fix: disable spatial indexes for such queries.
-
- 29 Jan, 2010 1 commit
-
-
Ramil Kalimullin authored
column is used for ORDER BY Problem: filesort isn't meant for null length sort data (e.g. char(0)), that leads to a server crash. Fix: disregard sort order if sort data record length is 0 (nothing to sort). mysql-test/r/select.result: Fix for bug#49897: crash in ptr_compare when char(0) NOT NULL column is used for ORDER BY - test result. mysql-test/t/select.test: Fix for bug#49897: crash in ptr_compare when char(0) NOT NULL column is used for ORDER BY - test case. sql/filesort.cc: Fix for bug#49897: crash in ptr_compare when char(0) NOT NULL column is used for ORDER BY - assert added as filesort cannot handle null length sort data. sql/sql_select.cc: Fix for bug#49897: crash in ptr_compare when char(0) NOT NULL column is used for ORDER BY - don't sort null length data e.g. in case of ORDER BY CHAR(0).
-
- 15 Dec, 2009 3 commits
-
-
Ramil Kalimullin authored
NULLable BIGINT and INT columns in comparison Problem: a consequence of the fix for 43668. Some Arg_comparator inner initialization missed, that may lead to unpredictable (wrong) comparison results. Fix: always properly initialize Arg_comparator before its usage. mysql-test/r/select.result: Fix for bug#49517: Inconsistent behavior while using NULLable BIGINT and INT columns in comparison -test result. mysql-test/t/select.test: Fix for bug#49517: Inconsistent behavior while using NULLable BIGINT and INT columns in comparison -test case. sql/item_cmpfunc.cc: Fix for bug#49517: Inconsistent behavior while using NULLable BIGINT and INT columns in comparison - now all Arg_comparator::set_cmp_func() set Arg_comparator::set_null to ensure its proper initialization in all cases (by default it's set to TRUE in constructors). sql/item_cmpfunc.h: Fix for bug#49517: Inconsistent behavior while using NULLable BIGINT and INT columns in comparison - now all Arg_comparator::set_cmp_func() set Arg_comparator::set_null to ensure its proper initialization in all cases (by default it's set to TRUE in constructors).
-
Georgi Kodinov authored
Merge the fix from 5.1-bugteam to 5.1-main
-
Sergey Petrunya authored
WL#2474 "Multi Range Read: Change the default MRR implementation to implement new MRR interface" WL#2475 "Batched range read functions for MyISAM/InnoDb" "Index condition pushdown for MyISAM/InnoDB" Igor's fix from sp1r-igor@olga.mysql.com-20080330055902-07614: There could be observed the following problems: 1. EXPLAIN did not mention pushdown conditions from on expressions in the 'extra' column. As a result if a query had no where conditions pushed down to a table, but had on conditions pushed to this table the 'extra' column in the EXPLAIN for the table missed 'using where'. 2. Conditions for ref access were not eliminated from on expressions though such conditions were eliminated from the where condition.
-
- 09 Dec, 2009 1 commit
-
-
Evgeny Potemkin authored
Arg_comparator uses Item_cache objects to store constants being compared when they're need a type conversion. Because this cache wasn't initialized properly Arg_comparator might produce wrong comparison result. The Arg_comparator::cache_converted_constant function now initializes cache prior to usage. mysql-test/r/select.result: Added a test case for he bug#49489. mysql-test/t/select.test: Added a test case for he bug#49489. sql/item_cmpfunc.cc: Bug#49489: Uninitialized cache led to a wrong result. The Arg_comparator::cache_converted_constant function now initializes cache prior to usage.
-
- 04 Dec, 2009 1 commit
-
-
Ramil Kalimullin authored
field='const1' AND field='const2' in some cases Building multiple equality predicates containing a constant which is compared as a datetime (with a field) we should take this fact into account and compare the constant with another possible constatns as datetimes as well. E.g. for the SELECT ... WHERE a='2001-01-01' AND a='2001-01-01 00:00:00' we should compare '2001-01-01' with '2001-01-01 00:00:00' as datetimes but not as strings. mysql-test/r/select.result: Fix for bug#49199: Optimizer handles incorrectly: field='const1' AND field='const2' in some cases - test result. mysql-test/t/select.test: Fix for bug#49199: Optimizer handles incorrectly: field='const1' AND field='const2' in some cases - test case. sql/item_cmpfunc.cc: Fix for bug#49199: Optimizer handles incorrectly: field='const1' AND field='const2' in some cases - adding a constant to Item_equal compare it as a datetime value with stored one if there's a date[time] field in a equality predicate. sql/item_cmpfunc.h: Fix for bug#49199: Optimizer handles incorrectly: field='const1' AND field='const2' in some cases - adding a constant to Item_equal compare it as a datetime value with stored one if there's a date[time] field in a equality predicate. sql/sql_select.cc: Fix for bug#49199: Optimizer handles incorrectly: field='const1' AND field='const2' in some cases - adding a constant to Item_equal compare it as a datetime value with stored one if there's a date[time] field in a equality predicate.
-
- 25 Nov, 2009 2 commits
-
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 1810.3961.7 > committer: Georgi Kodinov <joro@sun.com> > branch nick: B48291-5.0-bugteam > timestamp: Fri 2009-10-30 15:15:43 +0200 > message: > Bug #48291 : crash with row() operator,select into @var, and > subquery returning multiple rows > > Error handling was missing when handling subqueires in WHERE > and when assigning a SELECT result to a @variable. > This caused crash(es). > > Fixed by adding error handling code to both the WHERE > condition evaluation and to assignment to an @variable. > ------------------------------------------------------------
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 1810.3959.4 > revision-id: ramil@mysql.com-20091021090408-208mvwwrcroi2j8c > parent: azundris@mysql.com-20091021033856-ydodp4q42o58e7ka > committer: Ramil Kalimullin <ramil@mysql.com> > branch nick: b47019-5.0-bugteam > timestamp: Wed 2009-10-21 14:04:08 +0500 > message: > Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, > line 138 when forcing a spatial index > > Problem: "Spatial indexes can be involved in the search > for queries that use a function such as MBRContains() > or MBRWithin() in the WHERE clause". > Using spatial indexes for JOINs with =, <=> etc. > predicates is incorrect. > > Fix: disable spatial indexes for such queries.
-
- 13 Nov, 2009 1 commit
-
-
Jorgen Loland authored
init_read_record() - (records.cc:274) Item_cond::used_tables_cache was accessed in records.cc#init_read_record() without being initialized. It had not been initialized because it was wrongly assumed that the Item's variables would not be accessed, and hence quick_fix_field() was used instead of fix_fields() to save a few CPU cycles at creation time. The fix is to properly initilize the Item by replacing quick_fix_field() with fix_fields(). mysql-test/r/select.result: Add test for BUG#48052 mysql-test/t/select.test: Add test for BUG#48052 sql/sql_select.cc: Properly initialize Item_cond_and by calling fix_fields (instead of quick_fix_field) when the Item that "ANDs" WHERE clause conditions with HAVING clause conditions is created.
-
- 09 Nov, 2009 1 commit
-
-
Georgi Kodinov authored
memory The server was doing a bad class typecast causing setting of wrong value for the maximum number of items in an internal structure used in equality propagation. Fixed by not doing the wrong typecast and asserting the type of the Item where it should be done.
-
- 30 Oct, 2009 1 commit
-
-
Georgi Kodinov authored
subquery returning multiple rows Error handling was missing when handling subqueires in WHERE and when assigning a SELECT result to a @variable. This caused crash(es). Fixed by adding error handling code to both the WHERE condition evaluation and to assignment to an @variable.
-
- 21 Oct, 2009 1 commit
-
-
Ramil Kalimullin authored
line 138 when forcing a spatial index Problem: "Spatial indexes can be involved in the search for queries that use a function such as MBRContains() or MBRWithin() in the WHERE clause". Using spatial indexes for JOINs with =, <=> etc. predicates is incorrect. Fix: disable spatial indexes for such queries. mysql-test/r/select.result: Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, line 138 when forcing a spatial index - test result. mysql-test/t/select.test: Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, line 138 when forcing a spatial index - test case. sql/sql_select.cc: Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, line 138 when forcing a spatial index - disable spatial indexes for queries which use non-spatial conditions (e.g. NATURAL JOINs).
-
- 26 Jun, 2009 1 commit
-
-
Evgeny Potemkin authored
The TABLE::reginfo.impossible_range is used by the optimizer to indicate that the condition applied to the table is impossible. It wasn't initialized at table opening and this might lead to an empty result on complex queries: a query might set the impossible_range flag on a table and when the query finishes, all tables are returned back to the table cache. The next query that uses the table with the impossible_range flag set and an index over the table will see the flag and thus return an empty result. The open_table function now initializes the TABLE::reginfo.impossible_range variable. mysql-test/r/select.result: A test case for the bug#45266: Uninitialized variable lead to an empty result. mysql-test/t/select.test: A test case for the bug#45266: Uninitialized variable lead to an empty result. sql/sql_base.cc: Bug#45266: Uninitialized variable lead to an empty result. The open_table function now initializes the TABLE::reginfo.impossible_range variable. sql/sql_select.cc: Bug#45266: Uninitialized variable lead to an empty result. The open_table function now initializes the TABLE::reginfo.impossible_range variable. sql/structs.h: Bug#45266: Uninitialized variable lead to an empty result. A comment is added.
-
- 17 Jun, 2009 1 commit
-
-
Sergey Petrunia authored
* Fix test results to account for changes in previous cset
-
- 28 Apr, 2009 1 commit
-
-
Gleb Shchepa authored
Bug #40925: Equality propagation takes non indexed attribute Query execution plans and execution time of queries like select a, b, c from t1 where a > '2008-11-21' and b = a limit 10 depended on the order of equality operator parameters: "b = a" and "a = b" are not same. An equality propagation algorithm has been fixed: the substitute_for_best_equal_field function should not substitute a field for an equal field if both fields belong to the same table. mysql-test/r/select.result: Added test case for bug #40925. mysql-test/t/select.test: Added test case for bug #40925. sql/item.cc: Bug #40925: Equality propagation takes non indexed attribute An equality propagation algorithm has been fixed: the substitute_for_best_equal_field function should not substitute a field for an equal field if both fields belong to the same table.
-
- 16 Mar, 2009 1 commit
-
-
Ramil Kalimullin authored
select where .. (col=col and col=col) or ... (false expression) Problem: optimizer didn't take into account a singular case when we eliminated all the predicates at the AND level of WHERE. That may lead to wrong results. Fix: replace (a=a AND a=a...) with TRUE if we eliminated all the predicates. mysql-test/r/select.result: Fix for bug #42957: no results from select where .. (col=col and col=col) or ... (false expression) - test result. mysql-test/t/select.test: Fix for bug #42957: no results from select where .. (col=col and col=col) or ... (false expression) - test case. sql/sql_select.cc: Fix for bug #42957: no results from select where .. (col=col and col=col) or ... (false expression) - replacing equality predicates by multiple equality items check if we eliminate all the predicates at the AND level and replace them with TRUE if so.
-
- 28 Jan, 2009 1 commit
-
-
Alexey Kopytov authored
Various parts of code used different 'precision' arguments for sprintf("%g") when converting floating point numbers to a string. This led to differences in results in some cases depending on whether the text-based or prepared statements protocol is used for a query. Fixed by changing arguments to sprintf("%g") to always be 15 (DBL_DIG) so that results are consistent regardless of the protocol. This patch will be null-merged to 6.0 as the problem does not exists there (fixed by the patch for WL#2934). client/sql_string.cc: Use 15 (DBL_DIG) as a precision argument for sprintf(), as Field_double::val_str() does. libmysql/libmysql.c: Use 15 (DBL_DIG) as a precision argument for sprintf(), as Field_double::val_str() does. mysql-test/r/archive_gis.result: Fixed test results to take additional precision into account. mysql-test/r/func_group.result: Fixed test results to take additional precision into account. mysql-test/r/func_math.result: Fixed test results to take additional precision into account. mysql-test/r/func_str.result: Fixed test results to take additional precision into account. mysql-test/r/gis.result: Fixed test results to take additional precision into account. mysql-test/r/innodb_gis.result: Fixed test results to take additional precision into account. mysql-test/r/select.result: Fixed test results to take additional precision into account. mysql-test/r/sp.result: Fixed test results to take additional precision into account. mysql-test/r/type_float.result: Fixed test results to take additional precision into account. mysql-test/t/type_float.test: Fixed test results to take additional precision into account. sql/sql_string.cc: Use 15 (DBL_DIG) as a precision argument for sprintf(), as Field_double::val_str() does.
-
- 24 Dec, 2008 1 commit
-
-
Sergey Glukhov authored
Table could be marked dependent because it is either 1) an inner table of an outer join, or 2) it is a part of STRAIGHT_JOIN. In case of STRAIGHT_JOIN table->maybe_null should not be assigned. The fix is to set st_table::maybe_null to 'true' only for those tables which are used in outer join. mysql-test/r/select.result: test result mysql-test/t/select.test: test case sql/sql_select.cc: Table could be marked dependent because it is either 1) an inner table of an outer join, or 2) it is a part of STRAIGHT_JOIN. In case of STRAIGHT_JOIN table->maybe_null should not be assigned. The fix is to set st_table::maybe_null to 'true' only for those tables which are used in outer join. sql/sql_select.h: added comment
-
- 09 Dec, 2008 1 commit
-
-
Georgi Kodinov authored
Field_varstring::store The code that temporary saved the bitmaps of the read set and the write set so that it can set it to all columns for debug purposes was not expecting that the table->read_set and table->write_set can be the same. And was always saving both in sequence. As a result the original value was never restored. Fixed by saving & restoring the original value only once if the two sets are the same (in a special set of functions). mysql-test/r/select.result: Bug #37936: test case mysql-test/t/select.test: Bug #37936: test case sql/item_cmpfunc.cc: Bug #37936: don't save/restore twice if the read and write sets are the same sql/opt_range.cc: Bug #37936: don't save/restore twice if the read and write sets are the same sql/table.h: Bug #37936: Make a designated set of functions that save/restore both the read and the write sets in a single call.
-
- 17 Feb, 2008 1 commit
-
-
unknown authored
Problem is not about intervals and doesn't actually cause 'full table scan'. We have an optimization for DISTINCT when we have 'DISTINCT field_from_first_join_table' we don't need to read all the rows from the JOIN-ed table if we found one conforming row. It stopped working in 5.0 as we return NESTED_LOOP_OK if we came upon that case in the evaluate_join_record() and that doesn't break the recordreading loop in sub_select(). Fixed by returning NESTED_LOOP_NO_MORE_ROWS in this case. mysql-test/r/select.result: Bug #32942 now() - interval '7200' second is NOT pre-calculated, causing "full table scan". test result mysql-test/t/select.test: Bug #32942 now() - interval '7200' second is NOT pre-calculated, causing "full table scan" test case sql/sql_select.cc: Bug #32942 now() - interval '7200' second NOT pre-calculated, causing "full table scan" return NESTED_LOOP_NO_MORE_ROWS when we don't need to read rows from this table anymore
-
- 13 Feb, 2008 1 commit
-
-
unknown authored
type conversion. Instead of copying of whole character string from a temporary buffer, the server copied a short-living pointer to that string into a long-living structure. That has been fixed. mysql-test/r/select.result: Added test case for bug#33764. mysql-test/t/select.test: Added test case for bug#33764. sql/item_cmpfunc.cc: Fixed bug#33764. Copying of a pointer has been replaced with an optional copying of a whole array to a newly allocated memory space in case of a functional source item.
-
- 12 Feb, 2008 1 commit
-
-
unknown authored
but not collation. The problem here was that text literals in a view were always dumped with character set introducer. That lead to loosing collation information. The fix is to dump character set introducer only if it was in the original query. That is now possible because there is no problem any more of loss of character set of string literals in views -- after WL#4052 the view is dumped in the original character set. mysql-test/r/case.result: Update result file. mysql-test/r/compress.result: Update result file. mysql-test/r/ctype_collate.result: Update result file. mysql-test/r/date_formats.result: Update result file. mysql-test/r/ddl_i18n_koi8r.result: Update result file. mysql-test/r/ddl_i18n_utf8.result: Update result file. mysql-test/r/fulltext.result: Update result file. mysql-test/r/func_crypt.result: Update result file. mysql-test/r/func_encrypt.result: Update result file. mysql-test/r/func_if.result: Update result file. mysql-test/r/func_in.result: Update result file. mysql-test/r/func_like.result: Update result file. mysql-test/r/func_regexp.result: Update result file. mysql-test/r/func_set.result: Update result file. mysql-test/r/func_str.result: Update result file. mysql-test/r/func_time.result: Update result file. mysql-test/r/gis.result: Update result file. mysql-test/r/group_min_max.result: Update result file. mysql-test/r/mysqldump.result: Update result file. mysql-test/r/negation_elimination.result: Update result file. mysql-test/r/null.result: Update result file. mysql-test/r/select.result: Update result file. mysql-test/r/show_check.result: Update result file. mysql-test/r/sp-code.result: Update result file. mysql-test/r/ssl.result: Update result file. mysql-test/r/ssl_compress.result: Update result file. mysql-test/r/subselect.result: Update result file. mysql-test/r/temp_table.result: Update result file. mysql-test/r/type_blob.result: Update result file. mysql-test/r/view.result: Update result file. mysql-test/suite/binlog/r/binlog_stm_blackhole.result: Update result file. mysql-test/suite/rpl/r/rpl_get_lock.result: Update result file. mysql-test/suite/rpl/r/rpl_master_pos_wait.result: Update result file. mysql-test/t/view.test: Add a test case for Bug#32538. sql/item.cc: Do not dump character set introducer if it was not specified explicitly in the original query. sql/item.h: Add 'cs_specified' property to Item_string. sql/sql_yacc.yy: Set Item_string::cs_specified property to TRUE when character set introducer is explicitly specified.
-
- 17 Nov, 2007 1 commit
-
-
unknown authored
Comparison of a BIGINT NOT NULL column with a constant arithmetic expression that evaluates to NULL caused error 1048: "Column '...' cannot be null". Made convert_constant_item() check if the constant expression is NULL before attempting to store it in a field. Attempts to store NULL in a NOT NULL field caused query errors. sql/item_cmpfunc.cc: Fixed bug #32335. 1. Made convert_constant_item() check if the constant expression is NULL before attempting to store it in a field. Attempts to store NULL in a NOT NULL field caused query errors. 2. Also minor bug has been fixed: the thd->count_cuted_fields value was not restored in case of successful conversion. mysql-test/t/select.test: Added test case for bug #32335. mysql-test/r/select.result: Added test case for bug #32335.
-
- 10 Nov, 2007 1 commit
-
-
unknown authored
BETWEEN was more lenient with regard to what it accepted as a DATE/DATETIME in comparisons than greater-than and less-than were. ChangeSet makes < > comparisons similarly robust with regard to trailing garbage (" GMT-1") and "missing" leading zeros. Now all three comparators behave similarly in that they throw a warning for "junk" at the end of the data, but then proceed anyway if possible. Before < > fell back on a string- (rather than date-) comparison when a warning-condition was raised in the string-to-date conversion. Now the fallback only happens on actual errors, while warning- conditions still result in a warning being to delivered to the client. mysql-test/r/select.result: Show that we compare DATE/DATETIME-like strings as date(time)s now, rather than as bin-strings. Adjust older result as "2005-09-3a" is now correctly seen as "2005-09-3" + trailing garbage, rather than as "2005-09-30". mysql-test/t/select.test: Show that we compare DATE/DATETIME-like strings as date(time)s now, rather than as bin-strings. sql-common/my_time.c: correct/clarify date-related comments, particulary for check_date(). doxygenize comment while at it. sql/item_cmpfunc.cc: get_date_from_str() no longer signals an error when all we had was a warning-condition -- and one we already gave the user a warning for at that. Preamble doxygenized.
-
- 07 Nov, 2007 2 commits
-
-
unknown 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). mysql-test/r/select.result: Added a test case for bug #32103. mysql-test/t/select.test: Added a test case for bug #32103. sql/item.h: Use the correct constructor for Item_uint in Item_uint::new_item().
-
unknown authored
tables or more The problem was that the optimizer used the join buffer in cases when the result set is ordered by filesort. This resulted in the ORDER BY clause being ignored, and the records being returned in the order determined by the order of matching records in the last table in join. Fixed by relaxing the condition in make_join_readinfo() to take filesort-ordered result sets into account, not only index-ordered ones. mysql-test/r/select.result: Added a test case for bug #30666. mysql-test/t/select.test: Added a test case for bug #30666. sql/sql_select.cc: Relaxed the condition to determine when the join buffer usage must be disabled. The condition is now true for cases when the result set is ordered by filesort, that is when 'join->order && !join->skip_sort_order' is true.
-