1. 13 Sep, 2010 2 commits
    • Gleb Shchepa's avatar
      83c5552b
    • Gleb Shchepa's avatar
      Bug #55779: select does not work properly in mysql server · 79c1faa0
      Gleb Shchepa authored
                  Version "5.1.42 SUSE MySQL RPM"
      
      When a query was using a DATE or DATETIME value formatted
      using different formatting than "yyyy-mm-dd HH:MM:SS", a
      query with a greater-or-equal '>=' condition matched only
      greater values in an indexed TIMESTAMP column.
      
      The problem was introduced by the fix for the bug 46362
      and partially solved (for DATE and DATETIME columns only)
      by the fix for the bug 47925.
      
      The stored_field_cmp_to_item function has been modified
      to take into account TIMESTAMP columns like we do for
      DATE and DATETIME columns.
      79c1faa0
  2. 10 Sep, 2010 3 commits
  3. 09 Sep, 2010 5 commits
    • Alexey Kopytov's avatar
      Manual merge of the fix for bug #54190 and the addendum patch · 637c7529
      Alexey Kopytov authored
      to 5.5 (removed one test case as it is no longer valid).
      637c7529
    • Alexey Kopytov's avatar
      Addendum patch for bug #54190. · f563a012
      Alexey Kopytov authored
      The patch caused some test failures when merged to 5.5 because,
      unlike 5.1, it utilizes Item_cache_row to actually cache row
      values. The problem was that Item_cache_row::bring_value()
      essentially did nothing. In particular, it did not update its
      null_value, so all Item_cache_row objects were always having
      their null_values set to TRUE. This went unnoticed previously,
      but now when Arg_comparator::compare_row() actually depends on
      the row's null_value to evaluate the comparison, the problem
      has surfaced.
      
      Fixed by calling the underlying item's bring_value() and
      updating null_value in Item_cache_row::bring_value().
      
      Since the problem also exists in 5.1 code (albeit hidden, since
      the relevant code is not used anywhere), the addendum patch is
      against 5.1.
      f563a012
    • Alexey Kopytov's avatar
      Automerge. · df198b5f
      Alexey Kopytov authored
      df198b5f
    • Alexey Kopytov's avatar
      Bug #54190: Comparison to row subquery produces incorrect · 9066714c
      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.
      9066714c
    • Dmitry Shulga's avatar
      Fix mysql_client_test failure introduced by a patch for Bug#47485. · d88a11a7
      Dmitry Shulga authored
      The problem was that mysql_stmt_next_result() (new to 5.5)
      was not properly updated.
      d88a11a7
  4. 07 Sep, 2010 8 commits
    • Martin Hansson's avatar
      Merge of fix for Bug#51070. · 06b70326
      Martin Hansson authored
      06b70326
    • Martin Hansson's avatar
      Bug#51070: Query with a NOT IN subquery predicate returns a wrong result set · babebf9c
      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.
      babebf9c
    • Dmitry Shulga's avatar
      Auto-merge from mysql-5.1-bugteam. · 41709256
      Dmitry Shulga authored
      41709256
    • Dmitry Shulga's avatar
      Fixed bug #55421 - Protocol::end_statement(): Assertion `0' on · 70807d14
      Dmitry Shulga authored
      multi-table UPDATE IGNORE.
      The problem was that if there was an active SELECT statement
      during trigger execution, an error risen during the execution
      may cause a crash. The fix is to temporary reset LEX::current_select
      before trigger execution and restore it afterwards. This way
      errors risen during the trigger execution are processed as
      if there was no active SELECT.
      70807d14
    • Martin Hansson's avatar
    • Martin Hansson's avatar
      Bug#54543: update ignore with incorrect subquery leads to assertion failure: · 3d5b9792
      Martin Hansson authored
      inited==INDEX
      
      When an error occurs while sending the data in a temporary table there was no
      cleanup performed. This caused a failed assertion in the case when different
      access methods were used for populating the table vs. retrieving the data from
      the table if IGNORE was specified and sql_safe_updates = 0. In this case
      execution continues, but the handler expects to continue with the access
      method used for row retrieval.
      
      Fixed by doing the cleanup even if errors occur.
      3d5b9792
    • Dmitry Shulga's avatar
      Auto-merge from mysql-5.1-bugteam. · d439036a
      Dmitry Shulga authored
      d439036a
    • Dmitry Shulga's avatar
      Fixed bug #47485 - mysql_store_result returns a not NULL result set · 14dbc7e4
      Dmitry Shulga authored
      for a prepared statement.
      14dbc7e4
  5. 06 Sep, 2010 4 commits
  6. 03 Sep, 2010 1 commit
  7. 01 Sep, 2010 5 commits
    • Magne Mahre's avatar
      Bug#39932 "create table fails if column for FK is in different · 24fc7ca4
      Magne Mahre authored
                case than in corr index".
            
      Server was unable to find existing or explicitly created supporting
      index for foreign key if corresponding statement clause used field
      names in case different than one used in key specification and created
      yet another supporting index.
      In cases when name of constraint (and thus name of generated index)
      was the same as name of existing/explicitly created index this led
      to duplicate key name error.
            
      The problem was that unlike all other code Key_part_spec::operator==()
      compared field names in case sensitive fashion. As result routines
      responsible for getting rid of redundant generated supporting indexes
      for foreign key were not working properly for versions of field names
      using different cases.
      
      (backported from mysql-trunk)
      24fc7ca4
    • Bjorn Munch's avatar
      upmerge 56383 · 4698ed2b
      Bjorn Munch authored
      4698ed2b
    • Bjorn Munch's avatar
      merge from 5.5 · 21542111
      Bjorn Munch authored
      21542111
    • Alexander Nozdrin's avatar
      Auto-merge from mysql-5.5. · f8f23158
      Alexander Nozdrin authored
      f8f23158
    • Alexander Nozdrin's avatar
      Auto-merge from mysql-5.5-stage. · afe9d44c
      Alexander Nozdrin authored
      afe9d44c
  8. 31 Aug, 2010 3 commits
  9. 30 Aug, 2010 9 commits