1. 14 Jun, 2011 2 commits
    • Igor Babaev's avatar
      Fixed a typo in the patch for bug 794890. · 565b7fee
      Igor Babaev authored
      565b7fee
    • Igor Babaev's avatar
      Fixed LP bug #794890. · 56eb6d7e
      Igor Babaev authored
      Changed the code that processing of multi-updates and multi-deletes
      with multitable views at the prepare stage.
      
      A proper solution would be: never to perform any transformations of views
      before and at the prepare stage. Yet it would  require re-engineering
      of the code that checks privileges and updatability of views.
      Ultimately this re-engineering has to be done to provide a clean solution
      for INSERT/UPDATE/DELETE statements that use views.
      
      Fixed a valgrind problem in the function TABLE::use_index.
        
      56eb6d7e
  2. 09 Jun, 2011 2 commits
    • Igor Babaev's avatar
      Fixed LP bug #794909. · ab411f8f
      Igor Babaev authored
      The function generate_derived_keys did not take into account the fact
      that the last element in the array of keyuses could be just a barrier
      element. In some cases it could lead to a crash of the server.
      
      Also fixed a couple of other bugs in generate_derived_keys: the inner 
      loop in the body of if this function did not change the cycle variables
      properly.
      ab411f8f
    • Igor Babaev's avatar
      Fixed LP bug #794038. · 7f345153
      Igor Babaev authored
      INSERT/UPDATE/DELETE statement that used a temptable view v1 could lead to
      a crash if v1 was defined as a select from a mergeable view v2 that selected
      rows from a temptable view v3. 
       
      When INSERT/UPDATE/DELETE uses a view that is not updatable then field
      translation for the view should be created before the prepare phase.
      7f345153
  3. 06 Jun, 2011 2 commits
    • Igor Babaev's avatar
      Fixed LP bug #793436. · db0c3406
      Igor Babaev authored
      When looking for the execution plan of a derived table to be materialized
      JOIN::optimize finds  out that all joined tables of the derived table
      contain not more than one row then the derived table should be maretialized
      at the optimization stage.
      Added a test case for the bug.
      Adjusted results in other test cases.
      db0c3406
    • Igor Babaev's avatar
      Added two new flags for the optimizer switch: · 3bf08e54
      Igor Babaev authored
      'derived_merge':
        - if the flag is off then all derived tables are materialized
        - if the flag is on then mergeable derived tables are merged
      'derived_with_keys':
        - if the flag is off then no keys are created for derived tables
        - if the flag is on then for any derived table a key to access 
          the derived table may be created.
      
      Now by default both flags are on.
      Later the default values for the flags will be off to comply with
      the current behaviour of mysql-5.1. 
      
      Uncommented previously commented out test case from parts.partition_repair_myisam
      after having added an explicit requirement to materialize the derived
      table used in the test case.  
      
       
      3bf08e54
  4. 05 Jun, 2011 1 commit
  5. 04 Jun, 2011 1 commit
  6. 03 Jun, 2011 7 commits
  7. 02 Jun, 2011 5 commits
  8. 31 May, 2011 4 commits
  9. 30 May, 2011 5 commits
  10. 29 May, 2011 4 commits
  11. 28 May, 2011 7 commits