1. 13 Jan, 2011 6 commits
  2. 12 Jan, 2011 17 commits
    • Bjorn Munch's avatar
      null upmerge · d09a6f58
      Bjorn Munch authored
      d09a6f58
    • Bjorn Munch's avatar
      merge from 5.5-mtr · 61a1dc97
      Bjorn Munch authored
      61a1dc97
    • Bjorn Munch's avatar
      merge from 5.1-mtr · 7def3081
      Bjorn Munch authored
      7def3081
    • Evgeny Potemkin's avatar
      Auto-merge. · 7d2c7748
      Evgeny Potemkin authored
      7d2c7748
    • Bjorn Munch's avatar
      null upmerge · 31ecfd7d
      Bjorn Munch authored
      31ecfd7d
    • Bjorn Munch's avatar
      merge from 5.5 main · 45594d4b
      Bjorn Munch authored
      45594d4b
    • Bjorn Munch's avatar
      merge from 5.1 · c144d37f
      Bjorn Munch authored
      c144d37f
    • Dmitry Lenev's avatar
      Merged fix for bug #58499 "DEFINER-security view selecting from · 511a494c
      Dmitry Lenev authored
      INVOKER-security view access check wrong" into mysql-5.5 tree.
      511a494c
    • Bjorn Munch's avatar
      Bug #58841 Generalise handling of plugins in MTR mysql-test-run.pl script · 6d93b1e3
      Bjorn Munch authored
      Follow-up fix: mtr died if trying to run semisync test w/o the plugin
      6d93b1e3
    • Alexey Botchkov's avatar
      merging. · bbe2eff0
      Alexey Botchkov authored
      bbe2eff0
    • Dmitry Lenev's avatar
      Fix for bug #58499 "DEFINER-security view selecting from · d4c75324
      Dmitry Lenev authored
      INVOKER-security view access check wrong".
      
      When privilege checks were done for tables used from an 
      INVOKER-security view which in its turn was used from 
      a DEFINER-security view connection's active security
      context was incorrectly used instead of security context
      with privileges of the second view's creator.
      
      This meant that users which had enough rights to access
      the DEFINER-security view and as result were supposed to 
      be able successfully access it were unable to do so in 
      cases when they didn't have privileges on underlying tables 
      of the INVOKER-security view.
      
      This problem was caused by the fact that for INVOKER-security
      views TABLE_LIST::security_ctx member for underlying tables
      were set to 0 even in cases when particular view was used from 
      another DEFINER-security view. This meant that when checks of
      privileges on these underlying tables was done in
      setup_tables_and_check_access() active connection security 
      context was used instead of context corresponding to the 
      creator of caller view.
      
      This fix addresses the problem by ensuring that underlying
      tables of an INVOKER-security view inherit security context
      from the view and thus correct security context is used for
      privilege checks on underlying tables in cases when such view 
      is used from another view with DEFINER-security.
      
      mysql-test/r/view_grant.result:
        Added coverage for various combinations of DEFINER and
        INVOKER-security views, including test for bug #58499
        "DEFINER-security view selecting from INVOKER-security
        view access check wrong".
      mysql-test/t/view_grant.test:
        Added coverage for various combinations of DEFINER and
        INVOKER-security views, including test for bug #58499
        "DEFINER-security view selecting from INVOKER-security
        view access check wrong".
      sql/sql_view.cc:
        When opening a non-suid view ensure that its underlying 
        tables will get the same security context as use for
        checking privileges on the view, i.e. security context
        of view invoker. This context can be different from the
        security context which is currently active for connection 
        in cases when this non-suid view is used from a view with
        suid security. Inheriting security context in such situation
        allows correctly apply privileges of creator of suid view
        in checks for tables of non-suid view (since in this 
        situation creator/definer of suid view serves as invoker
        for non-suid view).
      d4c75324
    • Alexey Botchkov's avatar
      Bug #57321 crashes and valgrind errors from spatial types · 8b5db960
      Alexey Botchkov authored
              Item_func_spatial_collection::fix_length_and_dec didn't call parent's method, so
              the maybe_null was set to '0' after it. But in this case the result was
              just NULL, that caused wrong behaviour.
      
      per-file comments:
        mysql-test/r/gis.result
      Bug #57321 crashes and valgrind errors from spatial types 
              test result updated.
      
        mysql-test/t/gis.test
      Bug #57321 crashes and valgrind errors from spatial types 
              test case added.
        sql/item_geofunc.h
      Bug #57321 crashes and valgrind errors from spatial types 
              Item_func_geometry::fix_length_and_dec() called in
              Item_func_spatial_collection::fix_length_and_dec().
      8b5db960
    • Evgeny Potemkin's avatar
      Bug#59330: Incorrect result when comparing an aggregate function with · 5c56bce3
      Evgeny Potemkin authored
      TIMESTAMP.
      
      Item_cache::get_cache wasn't treating TIMESTAMP as a DATETIME value thus
      returning string cache for items with TIMESTAMP type. This led to incorrect
      TIMESTAMP -> INT conversion and to a wrong query result.
      
      Fixed by using Item::is_datetime function to check for DATETIME type group.
      
      
      mysql-test/r/type_timestamp.result:
        Added a test case for the bug#59330.
      mysql-test/t/type_timestamp.test:
        Added a test case for the bug#59330.
      sql/item.cc:
        Bug#59330: Incorrect result when comparing an aggregate function with
        TIMESTAMP.
        Item_cache::get_cache now uses is_datetime member function to detect DATETIME
        type group.
      5c56bce3
    • Ole John Aske's avatar
      Fix for bug#58818: Incorrect result for IN/ANY subquery · f188a6f9
      Ole John Aske authored
      If the ::single_value_transformer() find an existing HAVING condition it used
      to do the transformation:
                  
        1) HAVING cond -> (HAVING Cond) AND (cond_guard (Item_ref_null_helper(...))
            
      As the AND condition in 1) is Mc'Carty evaluated, the
      right side of the AND cond should be executed only if the 
      original 'HAVING evaluated' to true.
            
      However, as we failed to set 'top_level' for the tranformed HAVING condition,
      'abort_on_null' was FALSE after transformation. An
      UNKNOWN having condition will then not terminate evaluation of the
      transformed having condition, and we incorrectly continued
      into the Item_ref_null_helper() part.
      f188a6f9
    • Martin Hansson's avatar
      Merge of fix for Bug#58207. · 8e4fef51
      Martin Hansson authored
      8e4fef51
    • Bjorn Munch's avatar
      Bug #59182 output of mysql-test-run.pl - mismatch between col names and actual col contents · bf4b430e
      Bjorn Munch authored
      New patch, avoid global $opt_parallel
      I still prefer not to print workerid when not doing parallel
      bf4b430e
    • Martin Hansson's avatar
      Bug#58207: invalid memory reads when using default column value and · 73d88e80
      Martin Hansson authored
      tmptable needed
      
      The function DEFAULT() works by modifying the the data buffer pointers (often
      referred to as 'record' or 'table record') of its argument. This modification
      is done during name resolution (fix_fields().) Unfortunately, the same
      modification is done when creating a temporary table, because default values
      need to propagate to the new table.
      
      Fixed by skipping the pointer modification for fields that are arguments to
      the DEFAULT function.
      73d88e80
  3. 11 Jan, 2011 16 commits
  4. 10 Jan, 2011 1 commit