An error occurred fetching the project authors.
  1. 11 Dec, 2008 1 commit
    • Gleb Shchepa's avatar
      Bug #40761: Assert on sum function on · ce8ad64d
      Gleb Shchepa authored
                  IF(..., CAST(longtext AS UNSIGNED), signed_val)
                  (was: LEFT JOIN on inline view crashes server)
      
      Select from a LONGTEXT column wrapped with an expression
      like "IF(..., CAST(longtext_column AS UNSIGNED), smth_signed)"
      failed an assertion or crashed the server. IFNULL function was
      affected too.
      
      LONGTEXT column item has a maximum length of 32^2-1 bytes,
      at the same time this is a maximum possible length of any
      MySQL item. CAST(longtext_column AS UNSIGNED) returns some
      unsigned numeric result of length 32^2-1, so the result of
      IF/IFNULL function of this number and some other signed number
      will have text length of (32^2-1)+1=32^2 (one byte for the
      minus sign) - there is integer overflow, and the length is
      equal to zero. That caused assert/crash.
      
      The bug has been fixed by the same solution as in the CASE
      function implementation.
      ce8ad64d
  2. 28 Nov, 2008 1 commit
  3. 26 Nov, 2008 1 commit
    • Tatiana A. Nurnberg's avatar
      Bug#37553: MySql Error Compare TimeDiff & Time · ae0c6a94
      Tatiana A. Nurnberg authored
      We pretended that TIMEDIFF() would always return positive results;
      this gave strange results in comparisons of the TIMEDIFF(low,hi)<TIME(0)
      type that rendered a negative result, but still gave false in comparison.
      We also inadvertantly dropped the sign when converting times to
      decimal.
      
      CAST(time AS DECIMAL) handles signs of the times correctly.
      TIMEDIFF() marked up as signed. Time/date comparison code switched to
      signed for clarity.
      ae0c6a94
  4. 17 Nov, 2008 1 commit
    • Alexey Botchkov's avatar
      Bug#31616 div_precision_increment description looks wrong · 56dc6b2e
      Alexey Botchkov authored
      Item_func_div didn't calculate the precision of the result properly.
        The result of 5/0.0001 is 5000 so we have to add decimals of the divisor
        to the planned precision.
      
      per-file comments:
        mysql-test/r/type_newdecimal.result
      Bug#31616 div_precision_increment description looks wrong
          test result fixed
      
        mysql-test/t/type_newdecimal.test
      Bug#31616 div_precision_increment description looks wrong
          test case
      
        sql/item_func.cc
      Bug#31616 div_precision_increment description looks wrong
          precision must be increased with args[1]->decimals parameter
      56dc6b2e
  5. 11 Nov, 2008 1 commit
    • Sergey Vojtovich's avatar
      BUG#38842 - Fix for 25951 seems incorrect · 83f96dcf
      Sergey Vojtovich authored
      With fix for bug 25951 index hints are ignored for fulltext
      searches, as handling of fulltext indexes is different from
      handling regular indexes. Meaning it is not possible to
      implement true index hints support for fulltext indexes within
      the scope of current fulltext architecture.
      
      The problem is that prior to fix for bug 25951, some useful
      index hints still could be given for boolean mode searches.
      
      This patch implements special index hints support for fulltext
      indexes with the following characteristics:
      - all index hints are still ignored for NLQ mode searches -
        it cannot work without an index;
      - for 5.1 and up index hints FOR ORDER BY and FOR GROUP BY are
        still ignored for fulltext indexes;
      - boolean mode searches honor USE/FORCE/IGNORE INDEX hints;
      - as opposed to index hints for regular indexes, index hints
        for fulltext BOOLEAN mode searches affect the usage of the
        index for the whole query.
      83f96dcf
  6. 30 Jul, 2008 1 commit
    • Georgi Kodinov's avatar
      Bug#37662 nested if() inside sum() is parsed in exponential time · 425abb49
      Georgi Kodinov authored
            
      min() and max() functions are implemented in MySQL as macros.
      This means that max(a,b) is expanded to: ((a) > (b) ? (a) : (b))
      Note how 'a' is quoted two times.
      Now imagine 'a' is a recursive function call that's several 10s of levels deep.
      And the recursive function does max() with a function arg as well to dive into
      recursion.
      This means that simple function call can take most of the clock time.
      Identified and fixed several such calls to max()/min() : including the IF() 
      sql function implementation.
      425abb49
  7. 29 Mar, 2008 1 commit
  8. 28 Feb, 2008 1 commit
    • davi@mysql.com/endora.local's avatar
      Bug#33851 Passing UNSIGNED param to EXECUTE returns ERROR 1210 · 361262c7
      davi@mysql.com/endora.local authored
      The problem is that passing anything other than a integer to a limit
      clause in a prepared statement would fail. This limitation was introduced
      to avoid replication problems (e.g: replicating the statement with a
      string argument would cause a parse failure in the slave).
      
      The solution is to convert arguments to the limit clause to a integer
      value and use this converted value when persisting the query to the log.
      361262c7
  9. 15 Feb, 2008 1 commit
  10. 31 Jan, 2008 1 commit
    • evgen@moonbone.local's avatar
      Bug#30787: Stored function ignores user defined alias. · f967e247
      evgen@moonbone.local authored
      Simple subselects are pulled into upper selects. This operation substitutes the
      pulled subselect for the first item from the select list of the subselect.
      If an alias is defined for a subselect it is inherited by the replacement item.
      As this is done after fix_fields phase this alias isn't showed if the
      replacement item is a stored function. This happens because the Item_func_sp::make_field
      function makes send field from its result_field and ignores the defined alias.
      
      Now when an alias is defined the Item_func_sp::make_field function sets it for
      the returned field.
      f967e247
  11. 14 Jan, 2008 1 commit
    • mhansson/martin@linux-st28.site's avatar
      Bug#33143: Incorrect ORDER BY for ROUND()/TRUNCATE() result · effe27e3
      mhansson/martin@linux-st28.site authored
      The ROUND(X, D) function would change the Item::decimals field during
      execution to achieve the effect of a dynamic number of decimal digits.
      This caused a series of bugs:
      Bug #30617:Round() function not working under some circumstances in InnoDB
      Bug #33402:ROUND with decimal and non-constant cannot round to 0 decimal places
      Bug #30889:filesort and order by with float/numeric crashes server
      Fixed by never changing the number of shown digits for DECIMAL when
      used with a nonconstant number of decimal digits.
      effe27e3
  12. 06 Dec, 2007 1 commit
  13. 27 Nov, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #30355: Incorrect ordering of UDF results · 8c3d5135
      gkodinov/kgeorge@magare.gmz authored
      There's currently no way of knowing the determinicity of an UDF.
      And the optimizer and the sequence() UDFs were making wrong
      assumptions about what the is_const member means.
      Plus there was no implementation of update_system_tables()
      causing the optimizer to overwrite the information returned by
      the <udf>_init function.
      
      Fixed by equating the assumptions about the semantics of 
      is_const and providing a implementation of update_used_tables().
      Added a TODO item for the UDF API change needed to make a better 
      implementation.
      8c3d5135
  14. 26 Nov, 2007 1 commit
    • thek@adventure.(none)'s avatar
      Bug #32436 KILL QUERY completely deadlocks mysqld · 95bfde3d
      thek@adventure.(none) authored
      Sending several "KILL QUERY" statements to target a connection running
      "SELECT SLEEP" could freeze the server.
      
      The locking order in Item_func_sleep was wrong and this could lead to a
      dead lock.
      
      This patch solves the issue by resolving the locking order properly.
      95bfde3d
  15. 29 Oct, 2007 1 commit
    • gluh@mysql.com/eagle.(none)'s avatar
      Bug#30889: filesort and order by with float/numeric crashes server · 6b92ec4a
      gluh@mysql.com/eagle.(none) authored
      There are two problems with ROUND(X, D) on an exact numeric 
      (DECIMAL, NUMERIC type) field of a table:
      1) The implementation of the ROUND function would change the number of decimal
      places regardless of the value decided upon in fix_length_and_dec. When the
      number of decimal places is not constant, this would cause an inconsistent
      state where the number of digits was less than the number of decimal places,
      which crashes filesort.
      
      Fixed by not allowing the ROUND operation to add any more decimal places than
      was decided in fix_length_and_dec.
      
      2) fix_length_and_dec would allow the number of decimals to be greater than
      the maximium configured value for constant values of D. This led to the same 
      crash as in (1).
      
      Fixed by not allowing the above in fix_length_and_dec.
      6b92ec4a
  16. 24 Oct, 2007 1 commit
  17. 17 Oct, 2007 1 commit
  18. 04 Oct, 2007 2 commits
    • df@pippilotta.erinye.com's avatar
    • anozdrin/alik@station.'s avatar
      Fix for BUG#31035: select from function, group by result crasher. · 707f0674
      anozdrin/alik@station. authored
      This actually, fix for the patch for bug-27354. The problem with
      the patch was that Item_func_sp::used_tables() was updated, but
      Item_func_sp::const_item() was not. So, for Item_func_sp, we had
      the following inconsistency:
        - used_tables() returned RAND_TABLE, which means that the item
          can produce "random" results;
        - but const_item() returned TRUE, which means that the item is
          a constant one.
      
      The fix is to change Item_func_sp::const_item() behaviour: it must
      return TRUE (an item is a constant one) only if a stored function
      is deterministic and each of its arguments (if any) is a constant
      item.
      707f0674
  19. 28 Sep, 2007 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #30587: mysql crashes when trying to group by TIME div NUMBER · aa2d545d
      gkodinov/kgeorge@macbook.gmz authored
      When calculating the result length of an integer DIV function 
      the number of decimals was used without checking the result type
      first. Thus an uninitialized number of decimals was used for some 
      types. This caused an excessive amount of memory to be allocated 
      for the field's buffer and crashed the server.
      
       
      Fixed by using the number of decimals only for data types that 
      can have decimals and thus have valid decimals number.
      aa2d545d
  20. 22 Sep, 2007 1 commit
    • evgen@sunlight.local's avatar
      Bug#27216: functions with parameters of different date types may return wrong · 36bf417b
      evgen@sunlight.local authored
      type of the result.
      
      There are several functions that accept parameters of different types.
      The result field type of such functions was determined based on
      the aggregated result type of its arguments. As the DATE and the DATETIME
      types are represented by the STRING type, the result field type
      of the affected functions was always STRING for DATE/DATETIME arguments.
      The affected functions are COALESCE, IF, IFNULL, CASE, LEAST/GREATEST, CASE.
      
      Now the affected functions aggregate the field types of their arguments rather
      than their result types and return the result of aggregation as their result
      field type.
      The cached_field_type member variable is added to the number of classes to
      hold the aggregated result field type.
      The str_to_date() function's result field type now defaults to the
      MYSQL_TYPE_DATETIME.
      The agg_field_type() function is added. It aggregates field types with help
      of the Field::field_type_merge() function.
      The create_table_from_items() function now uses the 
      item->tmp_table_field_from_field_type() function to get the proper field
      when the item is a function with a STRING result type.
      36bf417b
  21. 05 Sep, 2007 1 commit
  22. 03 Aug, 2007 1 commit
    • bar@mysql.com/bar.myoffice.izhnet.ru's avatar
      Bug#28875 Conversion between ASCII and LATIN1 charsets does not function · 4eebfd09
      bar@mysql.com/bar.myoffice.izhnet.ru authored
      (Regression, caused by a patch for the bug 22646).
      Problem: when result type of date_format() was changed from
      binary string to character string, mixing date_format()
      with a ascii column in CONCAT() stopped to work.
      Fix:
      - adding "repertoire" flag into DTCollation class,
      to mark items which can return only pure ASCII strings.
      - allow character set conversion from pure ASCII to other character sets.
      4eebfd09
  23. 02 Aug, 2007 1 commit
  24. 01 Aug, 2007 1 commit
  25. 19 Jul, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #29338. · 73b2848f
      gshchepa/uchum@gleb.loc authored
      Optimization of queries with DETERMINISTIC functions in the
      WHERE clause was not effective: sequential scan was always
      used.
      Now a SF with the DETERMINISTIC flags is treated as constant
      when it's arguments are constants (or a SF doesn't has arguments).
      73b2848f
  26. 16 Jun, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #28625: · 8f09a374
      gshchepa/uchum@gleb.loc authored
      DECIMAL column was used instead of BIGINT for the minimal possible
      BIGINT (-9223372036854775808).
      
      The Item_func_neg::fix_length_and_dec has been adjusted to
      to inherit the type of the argument in the case when it's an 
      Item_int object whose value is equal to LONGLONG_MIN.
      8f09a374
  27. 15 Jun, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #27932: the function LOCATE returned NULL if any · 0f0d4720
      igor@olga.mysql.com authored
      of its arguments was evaluated to NULL, while the predicate
      LOCATE(str,NULL) IS NULL erroneously was evaluated to FALSE.
      
      This happened because the Item_func_locate::fix_length_and_dec
      method by mistake set the value of the maybe_null flag for 
      the function item to 0. In consequence of this the function 
      was considered as the one that could not ever return NULL.
      0f0d4720
  28. 13 Jun, 2007 2 commits
    • igor@olga.mysql.com's avatar
      Fixed bug #28980: the result of ROUND(<decimal expr>,<int column>) · 20ad5150
      igor@olga.mysql.com authored
      was erroneously converted to double, while the result of
      ROUND(<decimal expr>, <int literal>) was preserved as decimal.
      As a result of such a conversion the value of ROUND(D,A) could
      differ from the value of ROUND(D,val(A)) if D was a decimal expression.
      
      Now the result of the ROUND function is never converted to 
      double if the first argument is decimal.  
      20ad5150
    • joerg@trift2.'s avatar
      sql/item_func.cc · 018a5d40
      joerg@trift2. authored
          Improved check for thread identity in the "embedded" case,
          provided by Monty.
          
          This finishes the fixes for bug#27078.
      018a5d40
  29. 12 Jun, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #28992: trigger fails in pushbuild · 5ea9964b
      gkodinov/kgeorge@magare.gmz authored
       - fixed wrong test case for bug 20903
       - closed the dangling connections in trigger.test
       - GET_LOCK() and RELEASE_LOCK() now produce more detailed log
       - fixed an omission in GET_LOCK() : assign the thread_id when
          acquiring the lock.
      5ea9964b
  30. 03 Jun, 2007 1 commit
    • evgen@moonbone.local's avatar
      user_var.result: · 88147d5c
      evgen@moonbone.local authored
        Corrected test case result for the bug#28494.
      item_func.h, item_func.cc:
        Corrected function names after fix for the bug#28494.
      88147d5c
  31. 02 Jun, 2007 2 commits
    • evgen@moonbone.local's avatar
      item_func.cc: · 162a6b42
      evgen@moonbone.local authored
        Post fix for bug#28494.
        The Item_func_set_user_var::check method now silently doesn't use result_field
        if it isn't defined.
      162a6b42
    • evgen@moonbone.local's avatar
      Bug#28494: Grouping by Item_func_set_user_var produces incorrect result. · 49346467
      evgen@moonbone.local authored
      This is an additional fix.
      Item::val_xxx methods are supposed to use original data source and
      Item::val_xxx_result methods to use the item's result field. But for the
      Item_func_set_user_var class val_xxx_result methods were mapped to val_xxx
      methods. This leads, in particular, to producing bad sort keys and thus
      wrong order of the result set of queries with group by/order by clauses.
      
      The set of val_xxx_result methods is added to the Item_func_set_user_var
      class. It's the same as the val_xxx set of method but uses the result_field
      to return a value.
      49346467
  32. 31 May, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#28494: Grouping by Item_func_set_user_var produces incorrect result. · f70ae3a6
      evgen@moonbone.local authored
      The end_update() function uses the Item::save_org_in_field() function to
      save original values of items into the group buffer. But for the 
      Item_func_set_user_var this method was mapped to the save_in_field method.
      The latter function wrongly decides to use the result_field. This leads to
      saving incorrect value in the grouping buffer and wrong result of the whole
      query.
      
      The can_use_result_field argument of the bool type is added to the
      Item_func_set_user_var::save_in_field() function. If it is set to FALSE
      then the item's result field won't be used. Otherwise it will be detected
      whether the result field will be used (old behaviour).
      Two wrapping functions for the function above are added to the 
      Item_func_set_user_var class:
      the save_in_field(Field *field, bool no_conversions) - it calls the above
      function with the can_use_result_field set to TRUE.
      the save_org_in_field(Field *field) - same, but the can_use_result_field
      is set to FALSE.
      f70ae3a6
  33. 29 May, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #28605: SHOW CREATE VIEW with views using stored_procedures no · a6ebd634
      gkodinov/kgeorge@magare.gmz authored
       longer showing SP names.
      SHOW CREATE VIEW uses Item::print() methods to reconstruct the 
      statement text from the parse tree.
      The print() method for stored procedure calls needs allocate 
      space to print the function's quoted name.
      It was incorrectly calculating the length of the buffer needed 
      (was too short).
      Fixed to reflect the actual space needed.
      a6ebd634
  34. 23 May, 2007 2 commits
    • evgen@moonbone.local's avatar
      Bug#27563: Stored functions and triggers wasn't throwing an error when killed. · d1d58b5f
      evgen@moonbone.local authored
      If a stored function or a trigger was killed it had aborted but no error
      was thrown. This allows the caller statement to continue without a notice.
      This may lead to a wrong data being inserted/updated to/deleted as in such
      cases the correct result of a stored function isn't guaranteed. In the case
      of triggers it allows the caller statement to ignore kill signal and to
      waste time because of re-evaluation of triggers that always will fail
      because thd->killed flag is still on.
      
      Now the Item_func_sp::execute() and the sp_head::execute_trigger() functions
      check whether a function or a trigger were killed during execution and
      throws an appropriate error if so.
      Now the fill_record() function stops filling record if an error was reported
      through thd->net.report_error.
      d1d58b5f
    • mhansson@dl145s.mysql.com's avatar
      Bug #28250: Run-Time Check Failure #3 - The variable 'value' is · 85111f0a
      mhansson@dl145s.mysql.com authored
      being used without being def
      
      Inside method Item_func_unsigned::val_int, the variable value 
      can be returned without being initialized when the CAST argument
      is of type DECIMAL and has a NULL value. This gives a run-time 
      error when building debug binaries using Visual C++ 2005.
      
      Solution: Initialize value to 0
      85111f0a
  35. 16 May, 2007 1 commit
  36. 14 May, 2007 1 commit