An error occurred fetching the project authors.
  1. 27 Feb, 2013 1 commit
    • Gleb Shchepa's avatar
      Bug #16311231: MISSING DATA ON SUBQUERY WITH WHERE + XOR · f8cd565d
      Gleb Shchepa authored
      IN IN-CLAUSE USING MYISAM OR MEMORY ENGINE
      
      Backport from 5.6. Original message:
      
      The coincidences caused a data loss:
      * The query has IN subqueries nested twice,
      * the WHERE clause of the inner subquery refers to the
        outer field, and the whole WHERE clause returns FALSE,
      * the inner subquery has a LEFT JOIN that joins a single
        row with a row of NULLs; one of that NULL columns
        represents the select list of the subquery.
      
      Normally, that inner subquery should return empty record set.
      However, in our case:
      * the Item_is_not_null_test item goes constant, since
        its underlying field is NULL (because of LEFT JOIN ... ON 
        FALSE of const table row with a row of nulls);
      * we evaluate Item_is_not_null_test::val_int() as a part
        of fake HAVING expression of the transformed subquery;
      * as far as the underlying field is NULL, we optimize
        out the whole fake HAVING expression as FALSE as well
        as a whole subquery with a zero result:
        Impossible HAVING noticed after reading const tables";
      * thus, the optimizer ignores the presence of the WHERE
        clause (the WHERE expression is FALSE in our case, so
        the subquery should return empty set);
      * however, during the evaluation of the 
        Item_is_not_null_test::val_int() in the optimizer,
        it marked its "owner" with the "was_null" flag -- that
        forced the subquery to return UNKNOWN instead of empty
        set.
      That caused a wrong result.
      
      
      The problem is a regression of the small cleanup in
      the fix for the bug11827369 (the Item_is_not_null_test part)
      that conflicts with optimizations in the fix for the bug11752543.
      Before that regression the Item_is_not_null_test items
      never were constants.
      
      The fix is the rollback of Item_is_not_null_test parts
      of the bug11827369 fix.
      f8cd565d
  2. 23 Jan, 2013 1 commit
    • Gleb Shchepa's avatar
      Bug #11827369: ASSERTION FAILED: !THD->LEX->CONTEXT_ANALYSIS_ONLY · 19ea7c03
      Gleb Shchepa authored
      Some queries with the "SELECT ... FROM DUAL" nested subqueries
      failed with an assertion on debug builds.
      Non-debug builds were not affected.
      
      There were a few different issues with similar assertion
      failures on different queries:
      
      1. The first problem was related to the incomplete propagation
      of the "non-constant" item status from underlying subquery
      items to the outer item tree: in some cases non-constants were
      interpreted as constants and evaluated at the preparation stage
      (val_int() calls withing fix_fields() etc).
      
      Thus, the default implementation of Item_ref::const_item() from
      the Item parent class didn't take into account the "const_item"
      status of the referenced item tree -- it used the insufficient
      "used_tables() == 0" check instead. This worked in most cases
      since our "non-constant" functions like RAND() and SLEEP() set
      the RAND_TABLE_BIT in the used table map, so they aren't
      non-constant from Item_ref's "point of view". However, the
      "SELECT ... FROM DUAL" subquery may have an empty map of used
      tables, but at the same time subqueries are never "constant" at
      the context analysis stage (preparation, view creation etc).
      So, the non-contantness of such subqueries was missed.
      
      Fix: the Item_ref::const_item() function has been overloaded to
      take into account both (*ref)->const_item() status and tricky
      Item_ref::used_tables() return values, since the only
      (*ref)->const_item() call is not enough there.
      
      2. In some cases instead of the const_item() call we check a
      value of the Item::with_subselect field to recognize items
      with nested subqueries. However, the Item_ref class didn't
      propagate this value from the referenced item tree.
      
      Fix: Item::has_subquery() and Item_ref::has_subquery()
      functions have been backported from 5.6. All direct
      references to the with_subselect fields of nested items have
      been with the has_subquery() function call.
      
      3. The Item_func_regex class didn't propagate with_subselect
      as well, since it overloads the Item_func::fix_fields()
      function with insufficient fix_fields() implementation.
      
      Fix: the Item_func_regex::fix_fields() function has been
      modified to gather "constant" statuses from inner items.
      
      4. The Item_func_isnull::update_used_tables() function has
      a special branch for the underlying item where the maybe_null
      value is false: in this case it marks the Item_func_isnull
      as a "const_item" and sets the cached_value to false.
      However, the Item_func_isnull::val_int() was not in sync with
      update_used_tables(): it didn't take into account neither
      const_item_cache nor cached_value for the case of
      "args[0]->maybe_null == false optimization".
      As far as such an Item_func_isnull has "const_item() == true",
      it's ok to call Item_func_isnull::val_int() etc from outer
      items on preparation stage. In this case the server tried to
      call Item_func_isnull::args[0]->isnull(), and if the args[0]
      item contained a nested not-nullable subquery, it failed
      with an assertion.
      
      Fix: take the value of Item_func_isnull::const_item_cache into
      account in the val_int() function.
      
      5. The auxiliary Item_is_not_null_test class has a similar
      optimization in the update_used_tables() function as the
      Item_func_isnull class has, and the same issue in the val_int()
      function.
      In addition to that the Item_is_not_null_test::update_used_tables()
      doesn't update the const_item_cache value, so the "maybe_null"
      optimization is useless there. Thus, we missed some optimizations
      of cases like these (before and after the fix):
        <  <is_not_null_test>(a),
        ---
        >  <cache>(<is_not_null_test>(a)),
      or
        < having (<is_not_null_test>(a) and <is_not_null_test>(a))
        ---
        > having 1
      etc.
      
      Fix: update Item_is_not_null_test::const_item_cache in
      update_used_tables() and take in into account in val_int().
      19ea7c03
  3. 21 Dec, 2012 1 commit
    • Roy Lyseng's avatar
      Bug#15972635: Incorrect results returned in 32 table join with HAVING · 96c373c5
      Roy Lyseng authored
      The problem is a shift operation that is not 64-bit safe.
      The consequence is that used tables information for a join with 32 tables
      or more will be incorrect.
      
      Fixed by adding a type cast in Item_sum::update_used_tables().
      
      Also used the opportunity to fix some other potential bugs by adding an
      explicit type-cast to an integer in a left-shift operation.
      Some of them were quite harmless, but was fixed in order to get the same
      signed-ness as the other operand of the operation it was used in.
      
      sql/item_cmpfunc.cc
        Adjusted signed-ness for some integers in left-shift.
      
      sql/item_subselect.cc
        Added type-cast to nesting_map (which is a 32/64 bit type, so
        potential bug for deeply nested queries).
      
      sql/item_sum.cc
        Added type-cast to nesting_map (32/64-bit type) and table_map
        (64-bit type).
      
      sql/opt_range.cc
        Added type-cast to ulonglong (which is a 64-bit type).
      
      sql/sql_base.cc
        Added type-cast to nesting_map (which is a 32/64-bit type).
      
      sql/sql_select.cc
        Added type-cast to nesting_map (32/64-bit type) and key_part_map
        (64-bit type).
      
      sql/strfunc.cc
        Changed type-cast from longlong to ulonglong, to preserve signed-ness.
      96c373c5
  4. 25 Sep, 2012 1 commit
    • Tor Didriksen's avatar
      Backport · b079b388
      Tor Didriksen authored
      Bug #11764313 57135: CRASH IN ITEM_FUNC_CASE::FIND_ITEM WITH CASE WHEN
      Bug #11764818 57692: Crash in item_func_in::val_int() with ZEROFILL
      b079b388
  5. 17 May, 2012 1 commit
    • Mayank Prasad's avatar
      Bug#11766101 : 59140: LIKE CONCAT('%',@A,'%') DOESN'T MATCH WHEN @A CONTAINS LATIN1 STRING · 0581d1c4
      Mayank Prasad authored
      Issue/Cause:
      Issue is of memory corruption.During optimization phase, pattern to be matched in where 
      clause, is prepared. This is done in Item_func_concat::val_str() function which forms the
      resultant string (tmp_value) and return its pointer. In caller, Item_func_like::fix_fields, 
      pattern is made to point to this string (tmp_value). In further processing, tmp_value is 
      getting modified which causes pattern to have changed/wrong values.
      
      Fix:
      Allocate its own memroy location in caller, copy value of resultant string (tmp_value) 
      into that and make pattern to point to that. This makes sure no further changes to 
      tmp_value will affect pattern.
      
      0581d1c4
  6. 25 Jan, 2012 1 commit
    • Tor Didriksen's avatar
      Bug#13463415 63502: INCORRECT RESULTS OF BIGINT AND DECIMAL COMPARISON · 042bd151
      Tor Didriksen authored
      Bug#11758543 50756: BIGINT '100' MATCHES 1.001E2
      
      Expressions of the form
            BIGINT_COL <compare> <non-integer constant>
      
            should be done either as decimal, or float.
      
            Currently however, such comparisons are done as int,
            which means that the constant may be truncated,
            and yield false positives/negatives for all queries
            where compare is '>' '<' '>=' '<=' '=' '!='.
      
            BIGINT_COL IN <list of contstants>
            and
            BIGINT_COL BETWEEN <constant> AND <constant>
            are also affected.
      
      
      
      mysql-test/r/bigint.result:
        New tests.
      mysql-test/r/func_in.result:
        BIGINT <=> string comparison should be done as float,
        so a warning for the value 'abc' is appropriate.
      mysql-test/t/bigint.test:
        New tests.
      sql/item_cmpfunc.cc:
        In convert_constant_item() we verify that the constant item
        can be stored in the given field.
        For BIGINT columns (MYSQL_TYPE_LONGLONG) we must verify that the
        stored constant value is actually comparable as int,
        i.e. that the value was not truncated.
        
        For between: compare as int only if both arguments convert correctly to int.
      042bd151
  7. 19 Aug, 2011 1 commit
  8. 30 Jun, 2011 1 commit
  9. 21 Jun, 2011 1 commit
    • Alexander Nozdrin's avatar
      Patch for Bug 12652769 - 61470: CASE OPERATOR IN STORED ROUTINE RETAINS · 8b1566aa
      Alexander Nozdrin authored
      OLD VALUE OF INPUT PARAMETER.
      
      The user-visible problem was that CASE-control-flow function
      (not CASE-statement) misbehaved in stored routines under some
      circumstances. The problem resulted in a crash or wrong data
      returned. The error happened when expressions in CASE-function
      were not of the same character set.
      
      A CASE-function should return values of the same character set
      for all branches. Internally, that means a new Item-instance
      for the CONVERT(... USING <some charset>)-function is added
      to the item tree when needed. The problem was that such changes
      were not properly recorded using THD::change_item_tree(),
      thus dangling pointers remain in the item tree after
      THD::rollback_item_tree_changes(), which lead to undefined
      behavior (i.e. crash / wrong data) for subsequent executions of
      the stored routine.
      
      This bug was introduced by a patch for Bug 11753363
      (44793 - CHARACTER SETS: CASE CLAUSE, UCS2 OR UTF32, FAILURE).
      
      The fixed function is Item_func_case::fix_length_and_dec().
      New CONVERT-items are added in agg_item_set_converter(),
      which calls THD::change_item_tree().
      
      The problem was that an intermediate array was passed
      to agg_item_set_converter(). Thus, THD::change_item_tree() there
      was called on intermediate objects.
      
      Note: those intermediate objects are allocated on THD's
      memory root, so it's Ok to put them into "changed item lists".
      
      The fix is to track changes on the correct objects.
      8b1566aa
  10. 06 May, 2011 1 commit
    • Alexander Nozdrin's avatar
      Preliminary patch for Bug#11848763 / 60025 · 52efe3e0
      Alexander Nozdrin authored
      (SUBSTRING inside a stored function works too slow).
      
      Background:
        - THD classes derives from Query_arena, thus inherits the 'state'
          attribute and related operations (is_stmt_prepare() & co).
      
        - Although these operations are available in THD, they must not
          be used. THD has its own attribute to point to the active
          Query_arena -- stmt_arena.
      
        - So, instead of using thd->is_stmt_prepare(),
          thd->stmt_arena->is_stmt_prepare() must be used. This was the root
          cause of Bug 60025.
      
      This patch enforces the proper way of calling those operations.
      is_stmt_prepare() & co are declared as private operations
      in THD (thus, they are hidden from being called on THD instance).
      
      The patch tries to minimize changes in 5.5.
      52efe3e0
  11. 12 Apr, 2011 1 commit
    • Sergey Glukhov's avatar
      Bug#11766212 59270: NOT IN (YEAR( ... ), ... ) PRODUCES MANY VALGRIND WARNINGS · 33c2a5e7
      Sergey Glukhov authored
      Valgrind warning happens due to early null values check
      in Item_func_in::fix_length_and_dec(before item evaluation).
      As result null value items with uninitialized values are
      placed into array and it leads to valgrind warnings during
      value array sorting.
      The fix is to check null value after item evaluation, item
      is evaluated in in_array::set() method.
      
      
      mysql-test/r/func_in.result:
        test case
      mysql-test/t/func_in.test:
        test case
      sql/item_cmpfunc.cc:
        The fix is to check null value after item evaluation.
      33c2a5e7
  12. 01 Mar, 2011 1 commit
    • Alexander Barkov's avatar
      Bug#11753363 (bug#44793) CHARACTER SETS: CASE CLAUSE, UCS2 OR UTF32, FAILURE · 14263b22
      Alexander Barkov authored
      Problem: in case of string CASE/WHEN arguments with different
      character sets, Item_func_case::find_item() called comparator
      cmp_items[x] on mixed character set Items, so a 8-bit value could
      be errouneously referenced to as being utf16/utf32 value,
      which led to crash on DBUG_ASSERT() because of wrong value length.
      This was wrong, as string comparator expects arguments in the same
      character set.
      
      Fix: modify Item_func_case's argument list after calling
      agg_arg_charsets_for_comparison() - put the Items in "agg" array
      back to "args", because some of the Items in the "agg" array might
      have been changed to character set converters:
      - to Item_func_conv_charset for non-constant items
      - to Item_string for constant items
      
      In other words, perform the same substitution which is done in
      all other operations string comparison or string result operations:
      
      Replace
        CASE         latin1_item              WHEN utf16_item THEN ... END
      to
        CASE CONVERT(latin1_item USING utf16) WHEN utf16_item THEN ... END
      
      Replace
        CASE utf16_item WHEN         latin1_item              THEN ... END
      to
        CASE utf16_item WHEN CONVERT(latin1_item USING utf16) THEN ... END
      
      
        @ mysql-test/r/ctype_utf16.result
        @ mysql-test/r/ctype_utf32.result
        @ mysql-test/t/ctype_utf16.test
        @ mysql-test/t/ctype_utf32.test
        Adding tests
      
        @ sql/item_cmpfunc.cc
        Put "agg" back to "args".
      
        @ sql/sql_string.cc
        Backporting a fix for String::set_or_copy_aligned() from 5.6,
        for better test coverage:
        "SELECT _utf16 0x61" should expand the string to 0x0061 rather
        than to 0x000061.
        This fix was made in 5.6 under terms of "WL#4616 Implement UTF16-LE".
      14263b22
  13. 18 Feb, 2011 1 commit
    • Alexander Barkov's avatar
      Bug#60101 COALESCE with cp1251 tables causes [Err] 1267 - Illegal mix of collations · 0db53b19
      Alexander Barkov authored
            
      Problem:
        IF() did not copy collation derivation and repertoire from
        an argument if the opposite argument was NULL:
          IF(cond, res1, NULL)
          IF(cond, NULL, res2)
        only CHARSET_INFO pointer was copied.
        This resulted in illegal mix of collations error.
      
      Fix:
        copy all collation parameters from the non-NULL argument:
        CHARSET_INFO pointer, derivation, repertoire.
      0db53b19
  14. 17 Feb, 2011 2 commits
    • Tor Didriksen's avatar
      Revert 59685, as we now cache datetimes correctly. · b7a6dd45
      Tor Didriksen authored
      See also bug 11775312, all queries listed there now have the
      same results here, as they have in 5.1
      b7a6dd45
    • Tor Didriksen's avatar
      Bug #11766860 - 60085: CRASH IN ITEM::SAVE_IN_FIELD() WITH TIME DATA TYPE · 08c8d21f
      Tor Didriksen authored
      This assumption in Item_cache_datetime::cache_value_int
      was wrong:
      -  /* Assume here that the underlying item will do correct conversion.*/
      -  int_value= example->val_int_result();
      
      
      mysql-test/r/subselect_innodb.result:
        New test case.
      mysql-test/t/subselect_innodb.test:
        New test case.
      sql/item.cc:
        In Item_cache_datetime::cache_value_int()
         - call get_time() or get_date() depending on desired type
         - convert the returned MYSQL_TIME value to longlong depending on desired type
      sql/item.h:
        The cached int_value in Item_cache_datetime should not be unsigned:
         - it is used mostly in signed context
         - it can actually have negative value (for TIME data type)
      sql/item_cmpfunc.cc:
        Add comment on Bug#59685
      sql/item_subselect.cc:
        Add some DBUG_TRACE for easier bug-hunting.
      08c8d21f
  15. 11 Feb, 2011 1 commit
    • Sergey Glukhov's avatar
      Bug#59685 crash in String::length with date types · 654dd03f
      Sergey Glukhov authored
      The crash happens because Item_cache which is result
      holder for Item_subselect can't correctly convert
      a DATETIME value from string to int representation.
      The fix is to disable constant item convertion for
      subselect(partial rollback of bug52157 fix).
      
      
      mysql-test/r/type_date.result:
        test case
      mysql-test/t/type_date.test:
        test case
      sql/item_cmpfunc.cc:
        disable constant item convertion for subselects.
      654dd03f
  16. 09 Feb, 2011 2 commits
    • MySQL Build Team's avatar
      Backport into build-201102032246-5.1.52sp1 · 89b9934c
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 3520
      > revision-id: sergey.glukhov@oracle.com-20101214093303-wmo9mqcb8rz0wv9f
      > parent: tor.didriksen@oracle.com-20101213161301-81lprlbune7r98dl
      > committer: Sergey Glukhov <sergey.glukhov@oracle.com>
      > branch nick: mysql-5.1-bugteam
      > timestamp: Tue 2010-12-14 12:33:03 +0300
      > message:
      >   Fixed following problems:
      >   --Bug#52157 various crashes and assertions with multi-table update, stored function
      >   --Bug#54475 improper error handling causes cascading crashing failures in innodb/ndb
      >   --Bug#57703 create view cause Assertion failed: 0, file .\item_subselect.cc, line 846
      >   --Bug#57352 valgrind warnings when creating view
      >   --Recently discovered problem when a nested materialized derived table is used
      >     before being populated and it leads to incorrect result
      >   
      >   We have several modes when we should disable subquery evaluation.
      >   The reasons for disabling are different. It could be
      >   uselessness of the evaluation as in case of 'CREATE VIEW'
      >   or 'PREPARE stmt', or we should disable subquery evaluation
      >   if tables are not locked yet as it happens in bug#54475, or
      >   too early evaluation of subqueries can lead to wrong result
      >   as it happened in Bug#19077.
      >   Main problem is that if subquery items are treated as const
      >   they are evaluated in ::fix_fields(), ::fix_length_and_dec()
      >   of the parental items as a lot of these methods have
      >   Item::val_...() calls inside.
      >   We have to make subqueries non-const to prevent unnecessary
      >   subquery evaluation. At the moment we have different methods
      >   for this. Here is a list of these modes:
      >   
      >   1. PREPARE stmt;
      >   We use UNCACHEABLE_PREPARE flag.
      >   It is set during parsing in sql_parse.cc, mysql_new_select() for
      >   each SELECT_LEX object and cleared at the end of PREPARE in
      >   sql_prepare.cc, init_stmt_after_parse(). If this flag is set
      >   subquery becomes non-const and evaluation does not happen.
      >   
      >   2. CREATE|ALTER VIEW, SHOW CREATE VIEW, I_S tables which
      >      process FRM files
      >   We use LEX::view_prepare_mode field. We set it before
      >   view preparation and check this flag in
      >   ::fix_fields(), ::fix_length_and_dec().
      >   Some bugs are fixed using this approach,
      >   some are not(Bug#57352, Bug#57703). The problem here is
      >   that we have a lot of ::fix_fields(), ::fix_length_and_dec()
      >   where we use Item::val_...() calls for const items.
      >   
      >   3. Derived tables with subquery = wrong result(Bug19077)
      >   The reason of this bug is too early subquery evaluation.
      >   It was fixed by adding Item::with_subselect field
      >   The check of this field in appropriate places prevents
      >   const item evaluation if the item have subquery.
      >   The fix for Bug19077 fixes only the problem with
      >   convert_constant_item() function and does not cover
      >   other places(::fix_fields(), ::fix_length_and_dec() again)
      >   where subqueries could be evaluated.
      >   
      >   Example:
      >   CREATE TABLE t1 (i INT, j BIGINT);
      >   INSERT INTO t1 VALUES (1, 2), (2, 2), (3, 2);
      >   SELECT * FROM (SELECT MIN(i) FROM t1
      >   WHERE j = SUBSTRING('12', (SELECT * FROM (SELECT MIN(j) FROM t1) t2))) t3;
      >   DROP TABLE t1;
      >   
      >   4. Derived tables with subquery where subquery
      >      is evaluated before table locking(Bug#54475, Bug#52157)
      >   
      >   Suggested solution is following:
      >   
      >   -Introduce new field LEX::context_analysis_only with the following
      >    possible flags:
      >    #define CONTEXT_ANALYSIS_ONLY_PREPARE 1
      >    #define CONTEXT_ANALYSIS_ONLY_VIEW    2
      >    #define CONTEXT_ANALYSIS_ONLY_DERIVED 4
      >   -Set/clean these flags when we perform
      >    context analysis operation
      >   -Item_subselect::const_item() returns
      >    result depending on LEX::context_analysis_only.
      >    If context_analysis_only is set then we return
      >    FALSE that means that subquery is non-const.
      >    As all subquery types are wrapped by Item_subselect
      >    it allow as to make subquery non-const when
      >    it's necessary.
      89b9934c
    • MySQL Build Team's avatar
      Backport into build-201102032246-5.1.52sp1 · 9b656643
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 3452.13.54
      > revision-id: oystein.grovlen@oracle.com-20110112093715-tc076voaxwblqk8v
      > parent: georgi.kodinov@oracle.com-20110110130833-1c9q21mr7zoq07vg
      > committer: Oystein Grovlen <oystein.grovlen@oracle.com>
      > branch nick: mysql-5.1-security
      > timestamp: Wed 2011-01-12 10:37:15 +0100
      > message:
      >   Bug#59211: Select Returns Different Value for min(year) Function
      >   
      >   get_year_value() contains code to convert 2-digits year to
      >   4-digits.  The fix for Bug#49910 added a check on the size of
      >   the underlying field so that this conversion is not done for
      >   YEAR(4) values. (Since otherwise one would convert invalid
      >   YEAR(4) values to valid ones.)
      >   
      >   The existing check does not work when Item_cache is used, since
      >   it is not detected when the cache is based on a Field.  The
      >   reported change in behavior is due to Bug#58030 which added
      >   extra cached items in min/max computations.
      >   
      >   The elegant solution would be to implement
      >   Item_cache::real_item() to return the underlying Item.
      >   However, some side effects are observed (change in explain
      >   output) that indicates that such a change is not straight-
      >   forward, and definitely not appropriate for an MRU.
      >   
      >   Instead, a Item_cache::field() method has been added in order
      >   to get access to the underlying field.  (This field() method
      >   eliminates the need for Item_cache::eq_def() used in
      >   test_if_ref(), but in order to limit the scope of this fix,
      >   that code has been left as is.)
      9b656643
  17. 25 Jan, 2011 1 commit
  18. 19 Jan, 2011 1 commit
    • Martin Hansson's avatar
      Bug#59173: Failure to handle DATE(TIME) values where Year, Month or Day is · 03db0de6
      Martin Hansson authored
      ZERO
            
      When dates are represented internally as strings, i.e. when a string constant
      is compared to a date value, both values are converted to long integers,
      ostensibly for fast comparisons. DATE typed integer values are converted to
      DATETIME by multiplying by 1,000,000 (each digit pair representing hour,
      minute and second, respectively). But the mechanism did not distuinguish
      cached INTEGER values, already in correct format, from newly converted
      strings.
      
      Fixed by marking the INTEGER cache as being of DATETIME format.
      03db0de6
  19. 14 Jan, 2011 1 commit
    • Tor Didriksen's avatar
      Bug #59241 invalid memory read in do_div_mod with doubly assigned variables · 7bf23403
      Tor Didriksen authored
      Fix: copy my_decimal by value, to avoid dangling pointers.
      
      
      mysql-test/r/func_math.result:
        New test case.
      mysql-test/t/func_math.test:
        New test case.
      sql/item_cmpfunc.cc:
        No need to call fix_buffer_pointer() anymore.
      sql/item_func.cc:
        Copy my_decimal by value, to avoid dangling pointers.
      sql/my_decimal.h:
        Implement proper copy constructor and assignment operator for my_decimal.
      sql/sql_analyse.cc:
        No need to call fix_buffer_pointer() anymore.
      strings/decimal.c:
        Remove #line directive: it messes up TAGS and it confuses gdb when debugging.
      7bf23403
  20. 13 Jan, 2011 1 commit
    • Ole John Aske's avatar
      Fix for Bug#57034 incorrect OUTER JOIN result when joined on unique key · a6c41291
      Ole John Aske authored
      Item_equal::val_int() checked for NULL-values by checking Item::null_value
      *before* the respective ::store_value() and ::cmp(Item*) metods where called.
      
      As Item::null_value is set by these metods, the value of 'null_value' 
      is not valid until *after* ::store_value() or ::cmp() has
      been called for the Item object.
            
      Fix is to swap order of ::store_value()/::cmp() and checking of Item::null_value.
      This pattern is widely used other places inside item_cmpfunc.cc .
      
      a6c41291
  21. 12 Jan, 2011 1 commit
    • Oystein Grovlen's avatar
      Bug#59211: Select Returns Different Value for min(year) Function · 651313bf
      Oystein Grovlen authored
      get_year_value() contains code to convert 2-digits year to
      4-digits.  The fix for Bug#49910 added a check on the size of
      the underlying field so that this conversion is not done for
      YEAR(4) values. (Since otherwise one would convert invalid
      YEAR(4) values to valid ones.)
      
      The existing check does not work when Item_cache is used, since
      it is not detected when the cache is based on a Field.  The
      reported change in behavior is due to Bug#58030 which added
      extra cached items in min/max computations.
      
      The elegant solution would be to implement
      Item_cache::real_item() to return the underlying Item.
      However, some side effects are observed (change in explain
      output) that indicates that such a change is not straight-
      forward, and definitely not appropriate for an MRU.
      
      Instead, a Item_cache::field() method has been added in order
      to get access to the underlying field.  (This field() method
      eliminates the need for Item_cache::eq_def() used in
      test_if_ref(), but in order to limit the scope of this fix,
      that code has been left as is.)
      
      
      mysql-test/r/type_year.result:
        Added test case for Bug#59211.
      mysql-test/t/type_year.test:
        Added test case for Bug#59211.
      sql/item.h:
        Added function Item_cache::field() to get access to the
        underlying Field of a cached field Value.
      sql/item_cmpfunc.cc:
        Also check underlying fields of Item_cache, not just Item_Field,
        when checking whether the value is of type YEAR(4) or not.
      651313bf
  22. 28 Dec, 2010 1 commit
    • Kent Boortz's avatar
      - Added/updated copyright headers · 85323eda
      Kent Boortz authored
      - Removed files specific to compiling on OS/2
      - Removed files specific to SCO Unix packaging
      - Removed "libmysqld/copyright", text is included in documentation
      - Removed LaTeX headers for NDB Doxygen documentation
      - Removed obsolete NDB files
      - Removed "mkisofs" binaries
      - Removed the "cvs2cl.pl" script
      - Changed a few GPL texts to use "program" instead of "library"
      85323eda
  23. 16 Dec, 2010 1 commit
    • Martin Hansson's avatar
      Bug#54568: create view cause Assertion failed: 0, · ffdeb062
      Martin Hansson authored
      file .\item_subselect.cc, line 836
           
      IN quantified predicates are never executed directly. They are rather wrapped
      inside nodes called IN Optimizers (Item_in_optimizer) which take care of the
      execution. However, this is not done during query preparation. Unfortunately
      the LIKE predicate pre-evaluates constant right-hand side arguments even
      during name resolution. Likely this is meant as an optimization.
            
      Fixed by not pre-evaluating LIKE arguments in view prepare mode.
      
      Back-ported to 5.0s
      ffdeb062
  24. 14 Dec, 2010 1 commit
    • Sergey Glukhov's avatar
      Fixed following problems: · fcb83cbf
      Sergey Glukhov authored
      --Bug#52157 various crashes and assertions with multi-table update, stored function
      --Bug#54475 improper error handling causes cascading crashing failures in innodb/ndb
      --Bug#57703 create view cause Assertion failed: 0, file .\item_subselect.cc, line 846
      --Bug#57352 valgrind warnings when creating view
      --Recently discovered problem when a nested materialized derived table is used
        before being populated and it leads to incorrect result
      
      We have several modes when we should disable subquery evaluation.
      The reasons for disabling are different. It could be
      uselessness of the evaluation as in case of 'CREATE VIEW'
      or 'PREPARE stmt', or we should disable subquery evaluation
      if tables are not locked yet as it happens in bug#54475, or
      too early evaluation of subqueries can lead to wrong result
      as it happened in Bug#19077.
      Main problem is that if subquery items are treated as const
      they are evaluated in ::fix_fields(), ::fix_length_and_dec()
      of the parental items as a lot of these methods have
      Item::val_...() calls inside.
      We have to make subqueries non-const to prevent unnecessary
      subquery evaluation. At the moment we have different methods
      for this. Here is a list of these modes:
      
      1. PREPARE stmt;
      We use UNCACHEABLE_PREPARE flag.
      It is set during parsing in sql_parse.cc, mysql_new_select() for
      each SELECT_LEX object and cleared at the end of PREPARE in
      sql_prepare.cc, init_stmt_after_parse(). If this flag is set
      subquery becomes non-const and evaluation does not happen.
      
      2. CREATE|ALTER VIEW, SHOW CREATE VIEW, I_S tables which
         process FRM files
      We use LEX::view_prepare_mode field. We set it before
      view preparation and check this flag in
      ::fix_fields(), ::fix_length_and_dec().
      Some bugs are fixed using this approach,
      some are not(Bug#57352, Bug#57703). The problem here is
      that we have a lot of ::fix_fields(), ::fix_length_and_dec()
      where we use Item::val_...() calls for const items.
      
      3. Derived tables with subquery = wrong result(Bug19077)
      The reason of this bug is too early subquery evaluation.
      It was fixed by adding Item::with_subselect field
      The check of this field in appropriate places prevents
      const item evaluation if the item have subquery.
      The fix for Bug19077 fixes only the problem with
      convert_constant_item() function and does not cover
      other places(::fix_fields(), ::fix_length_and_dec() again)
      where subqueries could be evaluated.
      
      Example:
      CREATE TABLE t1 (i INT, j BIGINT);
      INSERT INTO t1 VALUES (1, 2), (2, 2), (3, 2);
      SELECT * FROM (SELECT MIN(i) FROM t1
      WHERE j = SUBSTRING('12', (SELECT * FROM (SELECT MIN(j) FROM t1) t2))) t3;
      DROP TABLE t1;
      
      4. Derived tables with subquery where subquery
         is evaluated before table locking(Bug#54475, Bug#52157)
      
      Suggested solution is following:
      
      -Introduce new field LEX::context_analysis_only with the following
       possible flags:
       #define CONTEXT_ANALYSIS_ONLY_PREPARE 1
       #define CONTEXT_ANALYSIS_ONLY_VIEW    2
       #define CONTEXT_ANALYSIS_ONLY_DERIVED 4
      -Set/clean these flags when we perform
       context analysis operation
      -Item_subselect::const_item() returns
       result depending on LEX::context_analysis_only.
       If context_analysis_only is set then we return
       FALSE that means that subquery is non-const.
       As all subquery types are wrapped by Item_subselect
       it allow as to make subquery non-const when
       it's necessary.
      
      
      mysql-test/r/derived.result:
        test case
      mysql-test/r/multi_update.result:
        test case
      mysql-test/r/view.result:
        test case
      mysql-test/suite/innodb/r/innodb_multi_update.result:
        test case
      mysql-test/suite/innodb/t/innodb_multi_update.test:
        test case
      mysql-test/suite/innodb_plugin/r/innodb_multi_update.result:
        test case
      mysql-test/suite/innodb_plugin/t/innodb_multi_update.test:
        test case
      mysql-test/t/derived.test:
        test case
      mysql-test/t/multi_update.test:
        test case
      mysql-test/t/view.test:
        test case
      sql/item.cc:
        --removed unnecessary code
      sql/item_cmpfunc.cc:
        --removed unnecessary checks
        --THD::is_context_analysis_only() is replaced with LEX::is_ps_or_view_context_analysis()
      sql/item_func.cc:
        --refactored context analysis checks
      sql/item_row.cc:
        --removed unnecessary checks
      sql/item_subselect.cc:
        --removed unnecessary code
        --added DBUG_ASSERT into Item_subselect::exec()
          which asserts that subquery execution can not happen
          if LEX::context_analysis_only is set, i.e. at context
          analysis stage.
        --Item_subselect::const_item()
          Return FALSE if LEX::context_analysis_only is set.
          It prevents subquery evaluation in ::fix_fields &
          ::fix_length_and_dec at context analysis stage.
      sql/item_subselect.h:
        --removed unnecessary code
      sql/mysql_priv.h:
        --Added new set of flags.
      sql/sql_class.h:
        --removed unnecessary code
      sql/sql_derived.cc:
        --added LEX::context_analysis_only analysis intialization/cleanup
      sql/sql_lex.cc:
        --init LEX::context_analysis_only field
      sql/sql_lex.h:
        --New LEX::context_analysis_only field
      sql/sql_parse.cc:
        --removed unnecessary code
      sql/sql_prepare.cc:
        --removed unnecessary code
        --added LEX::context_analysis_only analysis intialization/cleanup
      sql/sql_select.cc:
        --refactored context analysis checks
      sql/sql_show.cc:
        --added LEX::context_analysis_only analysis intialization/cleanup
      sql/sql_view.cc:
        --added LEX::context_analysis_only analysis intialization/cleanup
      fcb83cbf
  25. 18 Nov, 2010 1 commit
  26. 08 Nov, 2010 1 commit
    • Sergey Glukhov's avatar
      Fix for bug #54575: crash when joining tables with unique set column(backport from 5.1) · 0a29baba
      Sergey Glukhov authored
      Problem: a flaw (derefencing a NULL pointer) in the LIKE optimization
      code may lead to a server crash in some rare cases.
      
      Fix: check the pointer before its dereferencing.
      
      
      mysql-test/r/func_like.result:
        Fix for bug #54575: crash when joining tables with unique set column
          - test result.
      mysql-test/t/func_like.test:
        Fix for bug #54575: crash when joining tables with unique set column
          - test case.
      sql/item_cmpfunc.cc:
        Fix for bug #54575: crash when joining tables with unique set column
        - check res2 buffer pointer before its dereferencing 
          as it may be NULL in some cases.
      0a29baba
  27. 06 Oct, 2010 1 commit
    • Alexander Barkov's avatar
      Bug#55744 GROUP_CONCAT + CASE + ucs return garbage · 401e6c90
      Alexander Barkov authored
      Problem: CASE didn't work with a mixture of different character
      sets in THEN/ELSE in some cases.
      This happened because after character set aggregation
      newly created Item_func_conv_charset items corresponding
      to THEN/ELSE arguments were not put back to args[] array.
      
      Fix:
      put all Item_func_conv_charset back to args[].
      
      
        @ mysql-test/include/ctype_numconv.inc
        @ mysql-test/r/ctype_ucs.result
        Adding tests
      
        @ sql/item_cmpfunc.cc
        Put "agg" back to args[] after character set aggregation.
      401e6c90
  28. 09 Sep, 2010 1 commit
    • Alexey Kopytov's avatar
      Bug #54190: Comparison to row subquery produces incorrect · 453107bc
      Alexey Kopytov authored
                  result
      
      Row subqueries producing no rows were not handled as UNKNOWN
      values in row comparison expressions.
      
      That was a result of the following two problems:
      
      1. Item_singlerow_subselect did not mark the resulting row
      value as NULL/UNKNOWN when no rows were produced.
      
      2. Arg_comparator::compare_row() did not take into account that
      a whole argument may be NULL rather than just individual scalar
      values.
      
      Before bug#34384 was fixed, the above problems were hidden
      because an uninitialized (i.e. without any stored value) cached
      object would appear as NULL for scalar values in a row subquery
      returning an empty result. After the fix
      Arg_comparator::compare_row() would try to evaluate
      uninitialized cached objects.
      
      Fixed by removing the aforementioned problems.
      
      
      mysql-test/r/row.result:
        Added a test case for bug #54190.
      mysql-test/r/subselect.result:
        Updated the result for a test relying on wrong behavior.
      mysql-test/t/row.test:
        Added a test case for bug #54190.
      sql/item_cmpfunc.cc:
        If either of the argument rows is NULL, return NULL as the
        result of comparison.
      sql/item_subselect.cc:
        Adjust null_value for Item_singlerow_subselect depending on
        whether a row has been produced by the row subquery.
      453107bc
  29. 07 Sep, 2010 1 commit
    • Martin Hansson's avatar
      Bug#51070: Query with a NOT IN subquery predicate returns a wrong result set · 4f4d03a4
      Martin Hansson authored
            
      The EXISTS transformation has additional switches to catch the known corner
      cases that appear when transforming an IN predicate into EXISTS. Guarded
      conditions are used which are deactivated when a NULL value is seen in the
      outer expression's row. When the inner query block supplies NULL values,
      however, they are filtered out because no distinction is made between the
      guarded conditions; guarded NOT x IS NULL conditions in the HAVING clause that
      filter out NULL values cannot be de-activated in isolation from those that
      match values or from the outer expression or NULL's.
      
      The above problem is handled by making the guarded conditions remember whether
      they have rejected a NULL value or not, and index access methods are taking
      this into account as well. 
      
      The bug consisted of 
      
      1) Not resetting the property for every nested loop iteration on the inner
         query's result.
      
      2) Not propagating the NULL result properly from inner query to IN optimizer.
      
      3) A hack that may or may not have been needed at some point. According to a
         comment it was aimed to fix #2 by returning NULL when FALSE was actually
         the result. This caused failures when #2 was properly fixed. The hack is
         now removed.
      
      The fix resolves all three points.
      4f4d03a4
  30. 25 Aug, 2010 1 commit
    • Alexey Kopytov's avatar
      Bug#55077: Assertion failed: width > 0 && to != ((void *)0), · 04ae1aa9
      Alexey Kopytov authored
                 file .\dtoa.c
      
      The assertion failure was correct because the 'width' argument
      of my_gcvt() has the signed integer type, whereas the unsigned
      value UINT_MAX32 was being passed by the caller
      (Field_double::val_str()) leading to a negative width in
      my_gcvt().
      
      The following chain of problems was found by further analysis:
      
      1. The display width for a floating point number is calculated
      in Field_double::val_str() as either field_length or the
      maximum possible length of string representation of a floating
      point number, whichever is greater. Since in the bug's test
      case field_length is UINT_MAX32, we get the same value as the
      display width. This does not make any sense because for numeric
      values field_length only matters for ZEROFILL columns,
      otherwise it does not make sense to allocate that much memory
      just to print a number. Field_float::val_str() has a similar
      problem.
      
      2. Even if the above wasn't the case, we would still get a
      crash on a slightly different test case when trying to allocate
      UINT_MAX32 bytes with String::alloc() because the latter does
      not handle such large input values correctly due to alignment
      overflows.
      
      3. Even when String::alloc() is fixed to return an error when
      an alignment overflow occurs, there is still a problem because
      almost no callers check its return value, and
      Field_double::val_str() is not an exception (same for
      Field_float::val_str()).
      
      4. Even if all of the above wasn't the case, creating a
      Field_double object with UINT_MAX32 as its field_length does
      not make much sense either, since the .frm code limits it to
      MAX_FIELD_CHARLENGTH (255) bytes. Such a beast can only be
      created by create_tmp_field_from_item() from an Item with
      REAL_RESULT as its result_type() and UINT_MAX32 as its
      max_length.
      
      5. For the bug's test case, the above condition (REAL_RESULT
      Item with max_length = UINT_MAX32) was a result of
      Item_func_if::fix_length_and_dec() "shortcutting" aggregation
      of argument types when one of the arguments was a constant
      NULL. In this case, the attributes of the aggregated type were
      simply copied from the other, non-NULL argument, but max_length
      was still calculated as per the general, non-shortcut case, by
      choosing the greatest of argument's max_length, which is
      obviously not correct.
      
      The patch addresses all of the above problems, even though
      fixing the assertion failure for the particular test case would
      require only a subset of the above problems to be solved.
      
      
      client/sql_string.cc:
        Return an error in case of uint32 overflow in alignment.
        Also assert there was no overflow to help find such conditions
        in debug builds, since almost no callers check the return value
        of String::alloc().
      mysql-test/r/func_if.result:
        Add a test case for bug #55077.
      mysql-test/t/func_if.test:
        Add a test case for bug #55077.
      sql/field.cc:
        - Assert we don't operate with fields wider than 255 
        (MAX_FIELD_CHARLENGTH) bytes in both Field_float and  
        Field_double. 
        - Don't take field_length into account when calculating the 
        output buffer length.
        - Check the return value of String::alloc()
      sql/item_cmpfunc.cc:
        When shortcutting type aggregation, don't take the NULL 
        argument's max_length into account.
      sql/sql_string.cc:
        Return an error in case of uint32 overflow in alignment.
        Also assert there was no overflow to help find such conditions
        in debug builds, since almost no callers check the return value
        of String::alloc().
      04ae1aa9
  31. 19 Aug, 2010 1 commit
    • Alexander Barkov's avatar
      Bug#54916 GROUP_CONCAT + IFNULL truncates output · 7f987142
      Alexander Barkov authored
      Problem: a few functions did not calculate their max_length correctly.
      This is an after-fix for WL#2649 Number-to-string conversions".
      
      Fix: changing the buggy functions to calculate max_length
      using fix_char_length() introduced in WL#2649,
      instead of setting max_length directly
      
        mysql-test/include/ctype_numconv.inc
           Adding new tests
      
        mysql-test/r/ctype_binary.result
           Adding new tests
      
        mysql-test/r/ctype_cp1251.result
           Adding new tests
      
        mysql-test/r/ctype_latin1.result
           Adding new tests
      
        mysql-test/r/ctype_ucs.result
           Adding new tests
      
        mysql-test/r/ctype_utf8.result
           Adding new tests
      
        mysql-test/t/ctype_utf8.test
          Including ctype_numconv
      
        sql/item.h
          - Introducing new method fix_char_length_ulonglong(),
          for the cases when length is potentially greater
          than UINT_MAX32. This method removes a few
          instances of duplicate code, e.g. in item_strfunc.cc.
          - Setting collation in Item_copy properly. This change
          fixes wrong metadata on client side in some cases, when
          "binary" instead of the real character set was reported.
      
        sql/item_cmpfunc.cc
          - Using fix_char_length() and max_char_length() methods,
          instead of direct access to max_length, to calculate
          item length properly.
          - Moving count_only_length() in COALESCE after
          agg_arg_charsets_for_string_result(). The old
          order was incorrect and led to wrong length
          calucation in case of multi-byte character sets.
          
        sql/item_func.cc
          Fixing that count_only_length() didn't work
          properly for multi-byte character sets.
          Using fix_char_length() and max_char_length()
          instead of direct access to max_length.
      
        sql/item_strfunc.cc
          - Using fix_char_length(), fix_char_length_ulonglong(),
          max_char_length() instead of direct access to max_length.
          - Removing wierd condition: "if (collation.collation->mbmaxlen > 0)",
          which is never FALSE.
      7f987142
  32. 05 Aug, 2010 1 commit
    • Martin Hansson's avatar
      Bug#54568: create view cause Assertion failed: 0, · 0c81dcf3
      Martin Hansson authored
      file .\item_subselect.cc, line 836
      
      IN quantified predicates are never executed directly. They are rather wrapped
      inside nodes called IN Optimizers (Item_in_optimizer) which take care of the
      execution. However, this is not done during query preparation. Unfortunately
      the LIKE predicate pre-evaluates constant right-hand side arguments even
      during name resolution. Likely this is meant as an optimization.
      
      Fixed by not pre-evaluating LIKE arguments in view prepare mode.
      0c81dcf3
  33. 23 Jul, 2010 1 commit
  34. 19 Jul, 2010 1 commit
    • Evgeny Potemkin's avatar
      Bug#49771: Incorrect MIN/MAX for date/time values. · 4777370b
      Evgeny Potemkin authored
      This bug is a design flaw of the fix for the bug#33546. It assumed that an
      item can be used only in one comparison context, but actually it isn't the
      case. Item_cache_datetime is used to store result for MIX/MAX aggregate
      functions. Because Arg_comparator always compares datetime values as INTs when
      possible the Item_cache_datetime most time caches only INT value. But
      since all datetime values has STRING result type MIN/MAX functions are asked
      for a STRING value when the result is being sent to a client. The
      Item_cache_datetime was designed to avoid conversions and get INT/STRING
      values from an underlying item, but at the moment the values is asked
      underlying item doesn't hold it anymore thus wrong result is returned.
      Beside that MIN/MAX aggregate functions was wrongly initializing cached result
      and this led to a wrong result.
      
      The Item::has_compatible_context helper function is added. It checks whether
      this and given items has the same comparison context or can be compared as
      DATETIME values by Arg_comparator. The equality propagation optimization is
      adjusted to take into account that items which being compared as DATETIME
      can have different comparison contexts.
      The Item_cache_datetime now converts cached INT value to a correct STRING
      DATETIME value by means of number_to_datetime & my_TIME_to_str functions.
      The Arg_comparator::set_cmp_context_for_datetime helper function is added. 
      It sets comparison context of items being compared as DATETIMEs to INT if
      items will be compared as longlong.
      The Item_sum_hybrid::setup function now correctly initializes its result
      value.
      In order to avoid unnecessary conversions Item_sum_hybrid now states that it
      can provide correct longlong value if the item being aggregated can do it
      too.
      
      mysql-test/r/group_by.result:
        Added a test case for the bug#49771.
      sql/item.cc:
        Bug#49771: Incorrect MIN/MAX for date/time values.
        The equality propagation mechanism is adjusted to take into account that
        items which being compared as DATETIME can have different comparison
        contexts.
        The Item_cache_datetime now converts cached INT value to a correct STRING
        DATETIME/TIME value.
      sql/item.h:
        Bug#49771: Incorrect MIN/MAX for date/time values.
        The Item::has_compatible_context helper function is added. It checks whether
        this and given items has the same comparison context or can be compared as
        DATETIME values by Arg_comparator.
        Added Item_cache::clear helper function.
      sql/item_cmpfunc.cc:
        Bug#49771: Incorrect MIN/MAX for date/time values.
        The Arg_comparator::set_cmp_func now sets the correct comparison context
        for items being compared as DATETIME values.
      sql/item_cmpfunc.h:
        Bug#49771: Incorrect MIN/MAX for date/time values.
        The Arg_comparator::set_cmp_context_for_datetime helper function is added. 
        It sets comparison context of items being compared as DATETIMEs to INT if
        items will be compared as longlong.
      sql/item_sum.cc:
        Bug#49771: Incorrect MIN/MAX for date/time values.
        The Item_sum_hybrid::setup function now correctly initializes its result
        value.
      sql/item_sum.h:
        Bug#49771: Incorrect MIN/MAX for date/time values.
        In order to avoid unnecessary conversions Item_sum_hybrid now states that it
        can provide correct longlong value if the item being aggregated can do it
        too.
      4777370b
  35. 22 Jun, 2010 1 commit
    • Alexey Kopytov's avatar
      Bug#54477: Crash on IN / CASE with NULL arguments · 0e656039
      Alexey Kopytov authored
      Incorrect handling of NULL arguments could lead to a crash on
      the IN or CASE operations when either NULL arguments were
      passed explicitly as arguments (IN) or implicitly generated by
      the WITH ROLLUP modifier (both IN and CASE).
      
      Item_func_case::find_item() assumed all necessary comparators
      to be instantiated in fix_length_and_dec(). However, in the
      presence of WITH ROLLUP modifier, arguments could be
      substituted with an Item_null leading to an "unexpected"
      STRING_RESULT comparator being invoked.
      
      In addition to the problem identical to the above,
      Item_func_in::val_int() could crash even with explicitly passed
      NULL arguments due to an optimization in fix_length_and_dec()
      leading to NULL arguments being ignored during comparators
      creation.
      
      
      mysql-test/r/func_in.result:
        Test cases for bug#54477.
      mysql-test/t/func_in.test:
        Test cases for bug#54477.
      sql/item_cmpfunc.cc:
        Added additional checks for Item_nulls in 
        Item_func_case::find_item() and Item_func_in::val_int().
      0e656039
  36. 19 Jun, 2010 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug #54575: crash when joining tables with unique set column · 1614c3c1
      Ramil Kalimullin authored
      Problem: a flaw (derefencing a NULL pointer) in the LIKE optimization
      code may lead to a server crash in some rare cases.
      
      Fix: check the pointer before its dereferencing.
      
      
      mysql-test/r/func_like.result:
        Fix for bug #54575: crash when joining tables with unique set column
          - test result.
      mysql-test/t/func_like.test:
        Fix for bug #54575: crash when joining tables with unique set column
          - test case.
      sql/item_cmpfunc.cc:
        Fix for bug #54575: crash when joining tables with unique set column
          - check res2 buffer pointer before its dereferencing 
        as it may be NULL in some cases.
      1614c3c1
  37. 31 May, 2010 1 commit
    • Gleb Shchepa's avatar
      Bug #38745: MySQL 5.1 optimizer uses filesort for ORDER BY · fefbd756
      Gleb Shchepa authored
                  when it should use index
      
      Sometimes the LEFT/RIGHT JOIN with an empty table caused an
      unnecessary filesort.
      
      Sample query, where t1.i1 is indexed and t3 is empty:
      
        SELECT t1.*, t2.* FROM t1 JOIN t2 ON t1.i1 = t2.i2
                             LEFT JOIN t3 ON t2.i2 = t3.i3
          ORDER BY t1.i1 LIMIT 5;
      
      The server erroneously used an item of empty outer-joined
      table as a common constant of a Item_equal (multi-equivalence
      expression).
      By the fix for the bug 16590 the constant status of such
      an item has been propagated to st_table::const_key_parts
      map bits related to other Item_equal argument-related
      key parts (those are obviously not constant in our case).
      As far as test_if_skip_sort_order function skips constant
      prefixes of testing keys, this caused an ignorance of
      available indices, since some prefixes were marked as
      constant by mistake.
      
      
      mysql-test/r/order_by.result:
        Test case for bug #38745.
      mysql-test/t/order_by.test:
        Test case for bug #38745.
      sql/item.h:
        Bug #38745: MySQL 5.1 optimizer uses filesort for ORDER BY
                    when it should use index
        
        Item::is_outer_field() has been added and overloaded for
        Item_field and Item_ref classes.
      sql/item_cmpfunc.cc:
        Bug #38745: MySQL 5.1 optimizer uses filesort for ORDER BY
                    when it should use index
        
        Item_equal::update_const() and Item_equal::update_used_tables()
        have been updated to not take into account the constantness
        of outer-joined table items.
      fefbd756
  38. 31 Mar, 2010 1 commit
    • Mats Kindahl's avatar
      WL#5030: Split and remove mysql_priv.h · 23d8586d
      Mats Kindahl authored
      This patch:
      
      - Moves all definitions from the mysql_priv.h file into
        header files for the component where the variable is
        defined
      - Creates header files if the component lacks one
      - Eliminates all include directives from mysql_priv.h
      - Eliminates all circular include cycles
      - Rename time.cc to sql_time.cc
      - Rename mysql_priv.h to sql_priv.h
      23d8586d