An error occurred fetching the project authors.
  1. 17 May, 2007 1 commit
  2. 04 May, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #27807. · 6badb08c
      gkodinov/kgeorge@magare.gmz authored
      Non-correlated scalar subqueries may get executed
      in EXPLAIN at the optimization phase if they are
      part of a right hand sargable expression.
      If the scalar subquery uses a temp table to 
      materialize its results it will replace the 
      subquery structure from the parser with a simple
      select from the materialization table.
      As a result the EXPLAIN will crash as the 
      temporary materialization table is not to be shown
      in EXPLAIN at all.
      Fixed by preserving the original query structure
      right after calling optimize() for scalar subqueries
      with temp tables executed during EXPLAIN.
      6badb08c
  3. 26 Apr, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #27363: · bfa29e17
      gkodinov/kgeorge@magare.gmz authored
      Validity checks for nested set functions
      were not taking into account that the enclosed
      set function may be on a nest level that is
      lower than the nest level of the enclosing set
      function.
      Fixed by :
       - propagating max_sum_func_level
      up the enclosing set functions chain.
       - updating the max_sum_func_level of the 
         enclosing set function when the enclosed set
         function is aggregated above or on the same
         nest level of as the level of the enclosing 
         set function.
       - updating the max_arg_level of the enclosing
         set function on a reference that refers to
         an item above or on the same nest level
         as the level of the enclosing set function.
       - Treating both Item_field and Item_ref as possibly
         referencing items from outer nest levels.
      bfa29e17
  4. 15 Apr, 2007 2 commits
    • evgen@moonbone.local's avatar
      subselect.test, subselect.result: · 51badadd
      evgen@moonbone.local authored
        After merge fix.
      51badadd
    • 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
  5. 27 Mar, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #27348. · adc07255
      igor@olga.mysql.com authored
      If a set function with a outer reference s(outer_ref) cannot be aggregated 
      the outer query against which the reference has been resolved then MySQL
      interpretes s(outer_ref) in the same way as it would interpret s(const).
      Hovever the standard requires throwing an error in this situation.
      Added some code to support this requirement in ansi mode.
      Corrected another minor bug in Item_sum::check_sum_func.
       
      adc07255
  6. 22 Mar, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #27229: crash when a set function aggregated in outer · 8f9178e8
      igor@olga.mysql.com authored
      context was used as an argument of GROUP_CONCAT.
      Ensured correct setting of the depended_from field in references
      generated for set functions aggregated in outer selects.
      A wrong value of this field resulted in wrong maps returned by 
      used_tables() for these references.
      Made sure that a temporary table field is added for any set function
      aggregated in outer context when creation of a temporary table is 
      needed to execute the inner subquery. 
      8f9178e8
  7. 20 Mar, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #27257: queries containing subqueries with COUNT(*) · 19da4d39
      igor@olga.mysql.com authored
      aggregated in outer context returned wrong results.
      This happened only if the subquery did not contain any references
      to outer fields.
      As there were no references to outer fields the subquery erroneously
      was taken for non-correlated one.
      Now any set function aggregated in outer context makes the subquery
      correlated.
      19da4d39
  8. 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
  9. 01 Mar, 2007 1 commit
  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. 16 Feb, 2007 1 commit
  12. 30 Jan, 2007 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#21904 (parser problem when using IN with a double "(())") · f5ad4eed
      malff/marcsql@weblab.(none) authored
      Before this fix, a IN predicate of the form: "IN (( subselect ))", with two
      parenthesis, would be evaluated as a single row subselect: if the subselect
      returns more that 1 row, the statement would fail.
      
      The SQL:2003 standard defines a special exception in the specification,
      and mandates that this particular form of IN predicate shall be equivalent
      to "IN ( subselect )", which involves a table subquery and works with more
      than 1 row.
      
      This fix implements "IN (( subselect ))", "IN ((( subselect )))" etc
      as per the SQL:2003 requirement.
      
      All the details related to the implementation of this change have been
      commented in the code, and the relevant sections of the SQL:2003 spec
      are given for reference, so they are not repeated here.
      
      Having access to the spec is a requirement to review in depth this patch.
      f5ad4eed
  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. 19 Jan, 2007 1 commit
  15. 12 Dec, 2006 1 commit
  16. 20 Nov, 2006 1 commit
    • monty@mysql.com/nosik.monty.fi's avatar
      Remove compiler warnings · e8258798
      monty@mysql.com/nosik.monty.fi authored
      (Mostly in DBUG_PRINT() and unused arguments)
      Fixed bug in query cache when used with traceing (--with-debug)
      Fixed memory leak in mysqldump
      Removed warnings from mysqltest scripts (replaced -- with #)
      e8258798
  17. 07 Nov, 2006 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #11032: getObject() returns a String for a sub-query of type datetime · cf1ca923
      gkodinov/kgeorge@macbook.gmz authored
       - When returning metadata for scalar subqueries the actual type of the
         column was calculated based on the value type, which limits the actual
         type of a scalar subselect to the set of (currently) 3 basic types : 
         integer, double precision or string. This is the reason that columns
         of types other then the basic ones (e.g. date/time) are reported as
         being of the corresponding basic type.
         Fixed by storing/returning information for the column type in addition
         to the result type.
      cf1ca923
  18. 01 Nov, 2006 1 commit
    • igor@rurik.mysql.com's avatar
      Fixed bug #21727. · 2a7acba7
      igor@rurik.mysql.com authored
      This is a performance issue for queries with subqueries evaluation
      of which requires filesort.
      Allocation of memory for the sort buffer at each evaluation of a
      subquery may take a significant amount of time if the buffer is rather big.
      With the fix we allocate the buffer at the first evaluation of the
      subquery and reuse it at each subsequent evaluation.
      2a7acba7
  19. 20 Oct, 2006 1 commit
    • igor@rurik.mysql.com's avatar
      Fixed bug #23478. · d8b6f46a
      igor@rurik.mysql.com authored
      If elements a not top-level IN subquery were accessed by an index and 
      the subquery result set included  a NULL value then the quantified
      predicate that contained the subquery was evaluated to NULL when 
      it should return a non-null value.
      d8b6f46a
  20. 17 Oct, 2006 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug#21798: memory leak during query execution with subquery in column · f7b89376
      gkodinov/kgeorge@macbook.gmz authored
                  list using a function
      When executing dependent subqueries they are re-inited and re-exec() for 
      each row of the outer context.
      The cause for the bug is that during subquery reinitialization/re-execution,
      the optimizer reallocates JOIN::join_tab, JOIN::table in make_simple_join()
      and the local variable in 'sortorder' in create_sort_index(), which is
      allocated by make_unireg_sortorder().
      Care must be taken not to allocate anything into the thread's memory pool
      while re-initializing query plan structures between subquery re-executions.
      All such items mush be cached and reused because the thread's memory pool
      is freed at the end of the whole query.
      Note that they must be cached and reused even for queries that are not 
      otherwise cacheable because otherwise it will grow the thread's memory 
      pool every time a cacheable query is re-executed. 
      We provide additional members to the JOIN structure to store references 
      to the items that need to be cached.
      f7b89376
  21. 03 Oct, 2006 1 commit
  22. 25 Sep, 2006 1 commit
  23. 08 Sep, 2006 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #21540: Subqueries with no from and aggregate functions return · 5bc16fd9
      gkodinov/kgeorge@macbook.gmz authored
                  wrong results
       Mark the containing Item(s) (Item_subselect descendant usually) of 
       a subselect as containing aggregate functions if it has references
       to aggregates functions that are calculated outside its context.
       This tels end_send_group() not to make an Item_subselect descendant in
       select list a copy and causes the correct value being returned.
      5bc16fd9
  24. 31 Aug, 2006 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug#14654 : Cannot select from the same table twice within a UNION statement · e5bc4c7e
      gkodinov/kgeorge@macbook.gmz authored
       Made the parser to support parenthesis around UNION branches.
       This is done by amending the rules of the parser so it generates the correct
       structure.
       Currently it supports arbitrary subquery/join/parenthesis operations in the 
       EXISTS clause. 
       In the IN/scalar subquery case it will allow adding nested parenthesis only 
       if there is an UNION clause after the parenthesis. Otherwise it will just  
       treat the multiple nested parenthesis as a scalar expression.
       It adds extra lex level for ((SELECT ...) UNION ...) to accommodate for the
       UNION clause.
      e5bc4c7e
  25. 24 Aug, 2006 2 commits
  26. 03 Aug, 2006 1 commit
  27. 21 Jul, 2006 1 commit
  28. 20 Jul, 2006 1 commit
  29. 15 Jul, 2006 2 commits
    • igor@rurik.mysql.com's avatar
      Fixed bug #20869. · 38cd55a7
      igor@rurik.mysql.com authored
      The bug caused a crash of the server if a subquery with
      ORDER BY DESC used the range access method.
      The bug happened because the method QUICK_SELECT_DESC::reset
      was not reworked after MRR interface had been introduced.
      38cd55a7
    • igor@olga.mysql.com's avatar
      Fixed bug #20519. · 4de3186a
      igor@olga.mysql.com authored
      The bug was due to a loss happened during a refactoring made
      on May 30 2005 that modified the function JOIN::reinit.
      As a result of it for any subquery the value of offset_limit_cnt
      was not restored for the following executions. Yet the first 
      execution of the subquery made it equal to 0.
      The fix restores this value in the function JOIN::reinit.  
      4de3186a
  30. 11 Jul, 2006 1 commit
    • evgen@moonbone.local's avatar
      Fixed bug#18503: Queries with a quantified subquery returning empty set · 8ffda481
      evgen@moonbone.local authored
      may return a wrong result.
      
      An Item_sum_hybrid object has the was_values flag which indicates whether any
      values were added to the sum function. By default it is set to true and reset
      to false on any no_rows_in_result() call. This method is called only in
      return_zero_rows() function. An ALL/ANY subquery can be optimized by MIN/MAX
      optimization. The was_values flag is used to indicate whether the subquery
      has returned at least one row. This bug occurs because return_zero_rows() is
      called only when we know that the select will return zero rows before
      starting any scans but often such information is not known.
      In the reported case the return_zero_rows() function is not called and
      the was_values flag is not reset to false and yet the subquery return no rows
      Item_func_not_all and Item_func_nop_all functions return a wrong
      comparison result.
      
      The end_send_group() function now calls no_rows_in_result() for each item
      in the fields_list if there is no rows were found for the (sub)query.
      8ffda481
  31. 10 Jul, 2006 1 commit
    • evgen@moonbone.local's avatar
      Fixed bug#16302: Quantified subquery without any tables gives wrong results · d3418971
      evgen@moonbone.local authored
      The ALL/ANY subqueries are the subject of MIN/MAX optimization. The matter
      of this optimization is to embed MIN() or MAX() function into the subquery
      in order to get only one row by which we can tell whether the expression
      with ALL/ANY subquery is true or false.
      But when it is applied to a subquery like 'select a_constant' the reported bug
      occurs. As no tables are specified in the subquery the do_select() function 
      isn't called for the optimized subquery and thus no values have been added 
      to a MIN()/MAX() function and it returns NULL instead of a_constant.
      This leads to a wrong query result.
      
      For the subquery like 'select a_constant' there is no reason to apply
      MIN/MAX optimization because the subquery anyway will return at most one row.
      Thus the Item_maxmin_subselect class is more appropriate for handling such
      subqueries.
      
      The Item_in_subselect::single_value_transformer() function now checks
      whether tables are specified for the subquery. If no then this subselect is
      handled like a UNION using an Item_maxmin_subselect object.
      d3418971
  32. 25 May, 2006 1 commit
  33. 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
  34. 11 May, 2006 1 commit
    • gkodinov@mysql.com's avatar
      BUG#7549: Missing error message for invalid view selection with subquery. · 0486cfbe
      gkodinov@mysql.com authored
      When a view statement is compiled on CREATE VIEW time, most of the 
      optimizations should not be done. Finding the right optimization 
      for a subquery is one of them.
      Unfortunately the optimizer is resolving the column references of 
      the left expression of IN subqueries in the process of deciding 
      witch optimization to use (if needed). So there should be a 
      special case in Item_in_subselect::fix_fields() : check the 
      validity of the left expression of IN subqueries in CREATE VIEW 
      mode and then proceed as normal. 
      0486cfbe
  35. 23 Mar, 2006 1 commit
  36. 13 Mar, 2006 1 commit
    • evgen@sunlight.local's avatar
      Fixed bug#17366: Unchecked Item_int results in server crash · af660df0
      evgen@sunlight.local authored
      When there is conjunction of conds, the substitute_for_best_equal_field()
      will call the eliminate_item_equal() function in loop to build final
      expression. But if eliminate_item_equal() finds that some cond will always
      evaluate to 0, then that cond will be substituted by Item_int with value ==
      0. In this case on the next iteration eliminate_item_equal() will get that 
      Item_int and treat it as Item_cond. This is leads to memory corruption and
      server crash on cleanup phase.
      
      To the eliminate_item_equal() function was added DBUG_ASSERT for checking
      that all items treaten as Item_cond are really Item_cond.
      The substitute_for_best_equal_field() now checks that if
      eliminate_item_equal() returns Item_int and it's value is 0 then this 
      value is returned as the result of whole conjunction.
      af660df0
  37. 24 Feb, 2006 1 commit