1. 01 Feb, 2009 4 commits
  2. 31 Jan, 2009 8 commits
  3. 30 Jan, 2009 5 commits
  4. 29 Jan, 2009 14 commits
  5. 28 Jan, 2009 9 commits
    • Sergey Petrunia's avatar
      Merge · 8731a7c2
      Sergey Petrunia authored
      8731a7c2
    • Sergey Petrunia's avatar
      BUG#37822: Correlated subquery with IN and IS UNKNOWN provides wrong result · a9608b19
      Sergey Petrunia authored
      Item_in_optimizer::is_null() evaluated "NULL IN (SELECT ...)" to NULL regardless of
      whether subquery produced any records, this was a documented limitation.
      
      The limitation has been removed (see bugs 8804, 24085, 24127) now
      Item_in_optimizer::val_int() correctly handles all cases with NULLs. Make
      Item_in_optimizer::is_null() invoke val_int() to return correct values for
      "NULL IN (SELECT ...)".
      
      
      mysql-test/r/subselect.result:
        BUG#37822: Correlated subquery with IN and IS UNKNOWN provides wrong result
        - Testcase
      mysql-test/t/subselect.test:
        BUG#37822: Correlated subquery with IN and IS UNKNOWN provides wrong result
        - Testcase
      a9608b19
    • Gleb Shchepa's avatar
      b135bcab
    • Gleb Shchepa's avatar
      Bug #39069: <row constructor> IN <table-subquery> seriously · 334e249f
      Gleb Shchepa authored
                  messed up
      
      "ROW(...) IN (SELECT ... FROM DUAL)" always returned TRUE.
      
      Item_in_subselect::row_value_transformer rewrites "ROW(...)
      IN SELECT" conditions into the "EXISTS (SELECT ... HAVING ...)"
      form.
      For a subquery from the DUAL pseudotable resulting HAVING
      condition is an expression on constant values, so further
      transformation with optimize_cond() eliminates this HAVING
      condition and resets JOIN::having to NULL.
      Then JOIN::exec treated that NULL as an always-true-HAVING
      and that caused a bug.
      
      To distinguish an optimized out "HAVING TRUE" clause from
      "HAVING FALSE" we already have the JOIN::having_value flag.
      However, JOIN::exec() ignored JOIN::having_value as described
      above as if it always set to COND_TRUE.
      
      The JOIN::exec method has been modified to take into account
      the value of the JOIN::having_value field.
      
      
      mysql-test/r/subselect3.result:
        Added test case for bug #39069.
      mysql-test/t/subselect3.test:
        Added test case for bug #39069.
      sql/sql_select.cc:
        Bug #39069: <row constructor> IN <table-subquery> seriously
                    messed up
        
        The JOIN::exec method has been modified to take into account
        the value of the JOIN::having_value field.
      334e249f
    • Davi Arnaut's avatar
      Merge from 5.0-bugteam · a931ac09
      Davi Arnaut authored
      a931ac09
    • Magnus Svensson's avatar
      Merge · 87bbeddb
      Magnus Svensson authored
      87bbeddb
    • Magnus Svensson's avatar
      WL#4189 mtr.pl v2 · 818557b2
      Magnus Svensson authored
       - Fix faulty regex used for filtering out suspicious warnings, causing
         warnings/errors from previous tests to be reported
      818557b2
    • Davi Arnaut's avatar
      Remove test case for bug 40264. · aa0641dc
      Davi Arnaut authored
      Dirty close tricky does not work on Windows.
      
      mysql-test/r/query_cache_notembedded.result:
        Remove test case result.
      mysql-test/t/query_cache_notembedded.test:
        Remove test case.
      aa0641dc
    • Luis Soares's avatar
      Disabled test main.innodb_bug39438: · a95e5e01
      Luis Soares authored
      BUG#42383 2009-01-28 lsoares 
      "This fails in embedded and on windows. Note that this test is not run 
      on windows and on embedded in PB for main trees currently"
      a95e5e01