An error occurred fetching the project authors.
  1. 26 Apr, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#27590: Wrong DATE/DATETIME comparison. · 4747fa0c
      evgen@moonbone.local authored
      DATE and DATETIME can be compared either as strings or as int. Both
      methods have their disadvantages. Strings can contain valid DATETIME value
      but have insignificant zeros omitted thus became non-comparable with
      other DATETIME strings. The comparison as int usually will require conversion
      from the string representation and the automatic conversion in most cases is
      carried out in a wrong way thus producing wrong comparison result. Another
      problem occurs when one tries to compare DATE field with a DATETIME constant.
      The constant is converted to DATE losing its precision i.e. losing time part.
      
      This fix addresses the problems described above by adding a special
      DATE/DATETIME comparator. The comparator correctly converts DATE/DATETIME
      string values to int when it's necessary, adds zero time part (00:00:00)
      to DATE values to compare them correctly to DATETIME values. Due to correct
      conversion malformed DATETIME string values are correctly compared to other
      DATE/DATETIME values.
      
      As of this patch a DATE value equals to DATETIME value with zero time part.
      For example '2001-01-01' equals to '2001-01-01 00:00:00'.
      
      The compare_datetime() function is added to the Arg_comparator class.
      It implements the correct comparator for DATE/DATETIME values.
      Two supplementary functions called get_date_from_str() and get_datetime_value()
      are added. The first one extracts DATE/DATETIME value from a string and the
      second one retrieves the correct DATE/DATETIME value from an item.
      The new Arg_comparator::can_compare_as_dates() function is added and used
      to check whether two given items can be compared by the compare_datetime()
      comparator.
      Two caching variables were added to the Arg_comparator class to speedup the
      DATE/DATETIME comparison.
      One more store() method was added to the Item_cache_int class to cache int
      values.
      The new is_datetime() function was added to the Item class. It indicates
      whether the item returns a DATE/DATETIME value.
      4747fa0c
  2. 15 Apr, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#27321: Wrong subquery result in a grouping select. · 3113ce63
      evgen@moonbone.local authored
      The Item_outer_ref class based on the Item_direct_ref class was always used
      to represent an outer field. But if the outer select is a grouping one and the 
      outer field isn't under an aggregate function which is aggregated in that
      outer select an Item_ref object should be used to represent such a field.
      If the outer select in which the outer field is resolved isn't grouping then
      the Item_field class should be used to represent such a field.
      This logic also should be used for an outer field resolved through its alias
      name.
      
      Now the Item_field::fix_outer_field() uses Item_outer_field objects to
      represent aliased and non-aliased outer fields for grouping outer selects
      only.
      Now the fix_inner_refs() function chooses which class to use to access outer
      field - the Item_ref or the Item_direct_ref. An object of the chosen class
      substitutes the original field in the Item_outer_ref object.
      The direct_ref and the found_in_select_list fields were added to the
      Item_outer_ref class.
      3113ce63
  3. 20 Mar, 2007 1 commit
    • gkodinov/kgeorge@macbook.local's avatar
      Bug #24484: · 28962a76
      gkodinov/kgeorge@macbook.local authored
      To correctly decide which predicates can be evaluated with a given table
      the optimizer must know the exact set of tables that a predicate depends 
      on. If that mask is too wide (refer to non-existing tables) the optimizer
      can erroneously skip a predicate.
      One such case of wrong table usage mask were the aggregate functions.
      The have a all-1 mask (meaning depend on all tables, including non-existent
      ones).
      Fixed by making a real used_tables mask for the aggregates. The mask is
      constructed in the following way :
      1. OR the table dependency masks of all the arguments of the aggregate.
      2. If all the arguments of the function are from the local name resolution 
        context and it is evaluated in the same name resolution
        context where it is referenced all the tables from that name resolution 
        context are OR-ed to the dependency mask. This is to denote that an
        aggregate function depends on the number of rows it processes.
      3. Handle correctly the case of an aggregate function optimization (such that
        the aggregate function can be pre-calculated and made a constant).
      
      Made sure that an aggregate function is never a constant (unless subject of a 
      specific optimization and pre-calculation).  
      
      One other flaw was revealed and fixed in the process : references were 
      not calling the recalculation method for used_tables of their targets.
      28962a76
  4. 12 Mar, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #26738: incomplete string values in a result set column · 06a315de
      igor@olga.mysql.com authored
      when the column is to be read from a derived table column which 
      was specified as a concatenation of string literals.
      The bug happened because the Item_string::append did not adjust the
      value of Item_string::max_length. As a result of it the temporary 
      table column  defined to store the concatenation of literals was 
      not wide enough to hold the whole value.
      06a315de
  5. 09 Mar, 2007 2 commits
  6. 05 Mar, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #26560. · 08efa4e0
      igor@olga.mysql.com authored
      The flag alias_name_used was not set on for the outer references
      in subqueries. It resulted in replacement of any outer reference
      resolved against an alias for a full field name when the frm 
      representation of a view with a subquery was generated. 
      If the subquery and the outer query referenced the same table in
      their from lists this replacement effectively changed the meaning
      of the view and led to wrong results for selects from this view. 
      
      Modified several functions to ensure setting the right value of
      the alias_name_used flag for outer references resolved against
      aliases.
       
      08efa4e0
  7. 02 Mar, 2007 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #19342: · be755931
      gkodinov/kgeorge@macbook.gmz authored
      Several problems here :
       1. The conversion to double of an hex string const item
       was not taking into account the unsigned flag.
       
       2. IN was not behaving in the same was way as comparisons
       when performed over an INT/DATE/DATETIME/TIMESTAMP column
       and a constant. The ordinary comparisons in that case 
       convert the constant to an INTEGER value and do int 
       comparisons. Fixed the IN to do the same.
       
       3. IN is not taking into account the unsigned flag when 
       calculating <expr> IN (<int_const1>, <int_const2>, ...).
       Extended the implementation of IN to store and process
       the unsigned flag for its arguments.
      be755931
  8. 26 Feb, 2007 1 commit
  9. 25 Feb, 2007 1 commit
    • evgen@sunlight.local's avatar
      item.h: · e91347dd
      evgen@sunlight.local authored
        Post fix for bug#23800.
        Copy the table name of an Item_outer_ref to the conventional memory.
      e91347dd
  10. 21 Feb, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#23800: Outer fields in correlated subqueries is used in a temporary table · 9a233742
      evgen@moonbone.local authored
      created for sorting.
      
      Any outer reference in a subquery was represented by an Item_field object.
      If the outer select employs a temporary table all such fields should be
      replaced with fields from that temporary table in order to point to the 
      actual data. This replacement wasn't done and that resulted in a wrong
      subquery evaluation and a wrong result of the whole query.
      
      Now any outer field is represented by two objects - Item_field placed in the
      outer select and Item_outer_ref in the subquery. Item_field object is
      processed as a normal field and the reference to it is saved in the
      ref_pointer_array. Thus the Item_outer_ref is always references the correct
      field. The original field is substituted for a reference in the
      Item_field::fix_outer_field() function.
      
      New function called fix_inner_refs() is added to fix fields referenced from
      inner selects and to fix references (Item_ref objects) to these fields.
      
      The new Item_outer_ref class is a descendant of the Item_direct_ref class.
      It additionally stores a reference to the original field and designed to
      behave more like a field.
      9a233742
  11. 19 Feb, 2007 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #25831: Deficiencies in INSERT ... SELECT ... field name resolving. · d17ad7b3
      gkodinov/kgeorge@macbook.gmz authored
       Several problems fixed: 
        1. There was a "catch-all" context initialization in setup_tables()
          that was causing the table that we insert into to be visible in the 
          SELECT part of an INSERT .. SELECT .. statement with no tables in
          its FROM clause. This was making sure all the under-initialized
          contexts in various parts of the code are not left uninitialized.
          Fixed by removing the "catch-all" statement and initializing the 
          context in the parser.
        2. Incomplete name resolution context when resolving the right-hand
          values in the ON DUPLICATE KEY UPDATE ... part of an INSERT ... SELECT ...
          caused columns from NATURAL JOIN/JOIN USING table references in the
          FROM clause of the select to be unavailable.
          Fixed by establishing a proper name resolution context.
        3. When setting up the special name resolution context for problem 2
          there was no check for cases where an aggregate function without a
          GROUP BY effectively takes the column from the SELECT part of an 
          INSERT ... SELECT unavailable for ON DUPLICATE KEY UPDATE.
          Fixed by checking for that condition when setting up the name 
          resolution context.
      d17ad7b3
  12. 16 Feb, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#16630: The update fields of the INSERT .. SELECT .. ON DUPLICATE KEY · 7916d9e9
      evgen@moonbone.local authored
      UPDATE contains wrong data if the SELECT employs a temporary table.
      
      If the UPDATE values of the INSERT .. SELECT .. ON DUPLICATE KEY UPDATE
      statement contains fields from the SELECT part and the select employs a
      temporary table then those fields will contain wrong values because they
      aren't corrected to get data from the temporary table.
      
      The solution is to add these fields to the selects all_fields list,
      to store pointers to those fields in the selects ref_pointer_array and
      to access them via Item_ref objects.
      
      The substitution for Item_ref objects is done in the new function called 
      Item_field::update_value_transformer(). It is called through the
      item->transform() mechanism at the end of the select_insert::prepare()
      function.
      7916d9e9
  13. 26 Jan, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #24653. · 36df33d8
      igor@olga.mysql.com authored
      The bug report has demonstrated the following two problems.
      1. If an ORDER/GROUP BY list includes a constant expression being 
      optimized away and, at the same time, containing single-row
      subselects that return more that one row, no error is reported.
      Strictly speaking the standard allows to ignore error in this case.
      Yet, now a corresponding fatal error is reported in this case.
      2. If a query requires sorting by expressions containing single-row
      subselects that, however, return more than one row, then the execution
      of the query may cause a server crash. 
      To fix this some code has been added that blocks execution of a subselect
      item in case of a fatal error in the method Item_subselect::exec.
      36df33d8
  14. 23 Jan, 2007 1 commit
    • dlenev@mockturtle.local's avatar
      Proposed fix for bug#24491 "using alias from source table in insert ... · 2b63f106
      dlenev@mockturtle.local authored
      on duplicate key".
      
      INSERT ... SELECT ... ON DUPLICATE KEY UPDATE which was used in
      stored routine or as prepared statement and which in its ON DUPLICATE
      KEY clause erroneously tried to assign value to a column mentioned only
      in its SELECT part was properly emitting error on the first execution
      but succeeded on the second and following executions.
      
      Code which is responsible for name resolution of fields mentioned in
      UPDATE clause (e.g. see select_insert::prepare()) modifies table list
      and Name_resolution_context used in this process. It uses
      Name_resolution_context_state::save_state/restore_state() to revert
      these modifications. Unfortunately those two methods failed to revert
      properly modifications to TABLE_LIST::next_name_resolution_table
      and this broke name resolution process for successive executions.
      
      This patch fixes Name_resolution_context_state::save_state/restore_state()
      in such way that it properly handles TABLE_LIST::next_name_resolution_table.
      2b63f106
  15. 12 Jan, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #25398: crash in a trigger when using trigger fields · 86ef1cbf
      igor@olga.mysql.com authored
      in a select list.
      The objects of the Item_trigger_field class inherited the implementations
      of the methods copy_or_same, get_tmp_table_item and get_tmp_table_field
      from the class Item_field while they rather should have used the default
      implementations defined for the base class Item.
      It could cause catastrophic problems for triggers that used SELECTs
      with select list containing trigger fields such as NEW.<table column>
      under DISTINCT.
      86ef1cbf
  16. 11 Jan, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode. · 19ee0a94
      evgen@moonbone.local authored
      Currently in the ONLY_FULL_GROUP_BY mode no hidden fields are allowed in the
      select list. To ensure this each expression in the select list is checked
      to be a constant, an aggregate function or to occur in the GROUP BY list.
      The last two requirements are wrong and doesn't allow valid expressions like
      "MAX(b) - MIN(b)" or "a + 1" in a query with grouping by a.
      
      The correct check implemented by the patch will ensure that:
      any field reference in the [sub]expressions of the select list 
        is under an aggregate function or
        is mentioned as member of the group list or
        is an outer reference or
        is part of the select list element that coincide with a grouping element.
      
      The Item_field objects now can contain the position of the select list
      expression which they belong to. The position is saved during the
      field's Item_field::fix_fields() call.
      
      The non_agg_fields list for non-aggregated fields is added to the SELECT_LEX
      class. The SELECT_LEX::cur_pos_in_select_list now contains the position in the
      select list of the expression being currently fixed.
      19ee0a94
  17. 31 Dec, 2006 1 commit
    • kent@mysql.com/kent-amd64.(none)'s avatar
      my_strtoll10-x86.s: · 6523aca7
      kent@mysql.com/kent-amd64.(none) authored
        Corrected spelling in copyright text
      Makefile.am:
        Don't update the files from BitKeeper
      Many files:
        Removed "MySQL Finland AB & TCX DataKonsult AB" from copyright header
        Adjusted year(s) in copyright header 
      Many files:
        Added GPL copyright text
      Removed files:
        Docs/Support/colspec-fix.pl
        Docs/Support/docbook-fixup.pl
        Docs/Support/docbook-prefix.pl
        Docs/Support/docbook-split
        Docs/Support/make-docbook
        Docs/Support/make-makefile
        Docs/Support/test-make-manual
        Docs/Support/test-make-manual-de
        Docs/Support/xwf
      6523aca7
  18. 23 Dec, 2006 1 commit
  19. 22 Dec, 2006 1 commit
  20. 14 Dec, 2006 1 commit
    • monty@mysql.com/narttu.mysql.fi's avatar
      Fixed compiler warnings detected by option -Wshadow and -Wunused: · 88dd873d
      monty@mysql.com/narttu.mysql.fi authored
      - Removed not used variables and functions
      - Added #ifdef around code that is not used
      - Renamed variables and functions to avoid conflicts
      - Removed some not used arguments
      
      Fixed some class/struct warnings in ndb
      Added define IS_LONGDATA() to simplify code in libmysql.c
      
      I did run gcov on the changes and added 'purecov' comments on almost all lines that was not just variable name changes
      88dd873d
  21. 28 Nov, 2006 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      BUG#11927: Warnings shown for CAST( chr as signed) but not (chr + 0) · 42cd9567
      gkodinov/kgeorge@macbook.gmz authored
       When implicitly converting string fields to numbers the 
       string-to-number conversion error was not sent to the client.
       Added code to send the conversion error as warning.
       
       We also need to prevent generation of warnings from the places
       where val_xxx() methods are called for the sole purpose of updating
       the Item::null_value flag.
       To achieve that a special function is added (and called) : 
       update_null_value(). This function will set the no_errors flag and
       will call val_xxx(). The warning generation in Field_string::val_xxx()
       will use the flag when generating the conversion warnings. 
      42cd9567
  22. 09 Nov, 2006 1 commit
  23. 31 Oct, 2006 1 commit
    • sergefp@mysql.com's avatar
      BUG#8804: wrong results for NULL IN (SELECT ...) · 54a713aa
      sergefp@mysql.com authored
      Evaluate "NULL IN (SELECT ...)" in a special way: Disable pushed-down 
      conditions and their "consequences": 
       = Do full table scans instead of unique_[index_subquery] lookups.
       = Change appropriate "ref_or_null" accesses to full table scans in
         subquery's joins.
      Also cache value of NULL IN (SELECT ...) if the SELECT is not correlated 
      wrt any upper select.
      54a713aa
  24. 25 Oct, 2006 1 commit
  25. 09 Sep, 2006 1 commit
  26. 08 Sep, 2006 1 commit
  27. 07 Sep, 2006 1 commit
  28. 24 Aug, 2006 1 commit
  29. 20 Aug, 2006 1 commit
    • evgen@moonbone.local's avatar
      Fixed bug#21475: Wrongly applied constant propagation leads to a false comparison. · b4c2f3f8
      evgen@moonbone.local authored
      A date can be represented as an int (like 20060101) and as a string (like
      "2006.01.01"). When a DATE/TIME field is compared in one SELECT against both
      representations the constant propagation mechanism leads to comparison
      of DATE as a string and DATE as an int. In this example it compares 2006 and
      20060101 integers. Obviously it fails comparison although they represents the
      same date.
      
      
      Now the Item_bool_func2::fix_length_and_dec() function sets the comparison
      context for items being compared. I.e. if items compared as strings the
      comparison context is STRING.
      The constant propagation mechanism now doesn't mix items used in different
      comparison contexts. The context check is done in the
      Item_field::equal_fields_propagator() and in the change_cond_ref_to_const() 
      functions.
      
      Also the better fix for bug 21159 is introduced.
      b4c2f3f8
  30. 26 Jul, 2006 1 commit
  31. 25 Jul, 2006 1 commit
    • evgen@moonbone.local's avatar
      Fixed bug#19862: Sort with filesort by function evaluates function twice · 4ee2e07c
      evgen@moonbone.local authored
      When there is no index defined filesort is used to sort the result of a
      query. If there is a function in the select list and the result set should be
      ordered by it's value then this function will be evaluated twice. First time to
      get the value of the sort key and second time to send its value to a user.
      This happens because filesort when sorts a table remembers only values of its
      fields but not values of functions.
      All functions are affected. But taking into account that SP and UDF functions
      can be both expensive and non-deterministic a temporary table should be used 
      to store their results and then sort it to avoid twice SP evaluation and to 
      get a correct result.
      
      If an expression referenced in an ORDER clause contains a SP or UDF 
      function, force the use of a temporary table.
      
      A new Item_processor function called func_type_checker_processor is added
      to check whether the expression contains a function of a particular type.
      4ee2e07c
  32. 04 Jul, 2006 1 commit
  33. 30 Jun, 2006 2 commits
  34. 29 Jun, 2006 1 commit
  35. 13 Jun, 2006 1 commit
    • evgen@moonbone.local's avatar
      Fixed bug#16377: result of DATE/TIME functions were compared as strings which · 67de8c46
      evgen@moonbone.local authored
      can lead to a wrong result.
      
      All date/time functions has the STRING result type thus their results are
      compared as strings. The string date representation allows a user to skip 
      some of leading zeros. This can lead to wrong comparison result if a date/time 
      function result is compared to such a string constant.
      
      The idea behind this bug fix is to compare results of date/time functions
      and data/time constants as ints, because that date/time representation is 
      more exact. To achieve this the agg_cmp_type() is changed to take in the
      account that a date/time field or an date/time item should be compared 
      as ints.
      
      This bug fix is partially back ported from 5.0.
      
      The agg_cmp_type() function now accepts THD as one of parameters. 
      In addition, it now checks if a date/time field/function is present in the
      list. If so, it tries to coerce all constants to INT to make date/time
      comparison return correct result. The field for the constant coercion is
      taken from the Item_field or constructed from the Item_func. In latter case
      the constructed field will be freed after conversion of all constant items.
      Otherwise the result is same as before - aggregated with help of the
      item_cmp_type() function.
      
      From the Item_func_between::fix_length_and_dec() function removed the part
      which was converting date/time constants to int if possible. Now this is 
      done by the agg_cmp_type() function.
      
      The new function result_as_longlong() is added to the Item class. 
      It indicates that the item is a date/time item and result of it can be
      compared as int. Such items are date/time fields/functions.
      
      Correct val_int() methods are implemented for classes Item_date_typecast, 
      Item_func_makedate, Item_time_typecast, Item_datetime_typecast. All these
      classes are derived from Item_str_func and Item_str_func::val_int() converts
      its string value to int without regard to the date/time type of these items.
      
      Arg_comparator::set_compare_func() and Arg_comparator::set_cmp_func()
      functions are changed to substitute result type of an item with the INT_RESULT
      if the item is a date/time item and another item is a constant. This is done
      to get a correct result of comparisons like date_time_function() = string_constant.
      67de8c46
  36. 25 May, 2006 1 commit
  37. 24 May, 2006 1 commit
    • monty@mysql.com's avatar
      Remove dflt_field from field structure as this was only needed when createing... · 97b941d9
      monty@mysql.com authored
      Remove dflt_field from field structure as this was only needed when createing temporary table and I found another soultion that doesn't increase the size of the field structure for all table instances. (Better fix for bug #19089)
      Fixed compiler warnings
      Fixed valgrind warning in Item_date_add_intervall::eq. (Recoding of bugfix #19490)
      97b941d9
  38. 17 May, 2006 1 commit
    • evgen@moonbone.local's avatar
      Fixed bug#19077: A nested materialized derived table is used before being populated. · 1d820585
      evgen@moonbone.local authored
      The convert_constant_item() function converts constant items to ints on
      prepare phase to optimize execution speed. In this case it tries to evaluate
      subselect which contains a derived table and is contained in a derived table. 
      All derived tables are filled only after all derived tables are prepared.
      So evaluation of subselect with derived table at the prepare phase will
      return a wrong result.
      
      A new flag with_subselect is added to the Item class. It indicates that
      expression which this item represents is a subselect or contains a subselect.
      It is set to 0 by default. It is set to 1 in the Item_subselect constructor
      for subselects.
      For Item_func and Item_cond derived classes it is set after fixing any argument
      in Item_func::fix_fields() and Item_cond::fix_fields accordingly.
      The convert_constant_item() function now doesn't convert a constant item
      if the with_subselect flag set in it. 
      1d820585