1. 23 Jul, 2008 1 commit
    • Georgi Kodinov's avatar
      Bug#37830 : ORDER BY ASC/DESC - no difference · 436f1dc4
      Georgi Kodinov authored
                        
      Range scan in descending order for c <= <col> <= c type of
      ranges was ignoring the DESC flag.
      However some engines like InnoDB have the primary key parts 
      as a suffix for every secondary key.
      When such primary key suffix is used for ordering ignoring 
      the DESC is not valid.
      But we generally would like to do this because it's faster.
                  
      Fixed by performing only reverse scan if the primary key is used.
      Removed some dead code in the process.
      436f1dc4
  2. 22 Jul, 2008 1 commit
  3. 21 Jul, 2008 1 commit
  4. 24 Jul, 2008 1 commit
  5. 21 Jul, 2008 1 commit
  6. 19 Jul, 2008 2 commits
  7. 18 Jul, 2008 2 commits
  8. 17 Jul, 2008 2 commits
  9. 16 Jul, 2008 5 commits
  10. 15 Jul, 2008 3 commits
    • Sergey Petrunia's avatar
      Merge · 63bfaa46
      Sergey Petrunia authored
      63bfaa46
    • Kristofer Pettersson's avatar
      auto merge · 44b44795
      Kristofer Pettersson authored
      44b44795
    • Sergey Petrunia's avatar
      BUG#35478: sort_union() returns bad data when sort_buffer_size is hit · 2951f00b
      Sergey Petrunia authored
      - In QUICK_INDEX_MERGE_SELECT::read_keys_and_merge: when we got table->sort from Unique,
        tell init_read_record() not to use rr_from_cache() because a) rowids are already sorted
        and b) it might be that the the data is used by filesort(), which will need record rowids
        (which rr_from_cache() cannot provide).
      - Fully de-initialize the table->sort read in QUICK_INDEX_MERGE_SELECT::get_next(). This fixes BUG#35477.
      (bk trigger: file as fix for BUG#35478).
      2951f00b
  11. 14 Jul, 2008 3 commits
    • Marc Alff's avatar
      Merge · 504f7e2d
      Marc Alff authored
      504f7e2d
    • Marc Alff's avatar
      Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on · 0816ee6d
      Marc Alff authored
      build)
      
      The crash was caused by freeing the internal parser stack during the parser
      execution.
      This occured only for complex stored procedures, after reallocating the parser
      stack using my_yyoverflow(), with the following C call stack:
      - MYSQLparse()
      - any rule calling sp_head::restore_lex()
      - lex_end()
      - x_free(lex->yacc_yyss), xfree(lex->yacc_yyvs)
      
      The root cause is the implementation of stored procedures, which breaks the
      assumption from 4.1 that there is only one LEX structure per parser call.
      
      The solution is to separate the LEX structure into:
      - attributes that represent a statement (the current LEX structure),
      - attributes that relate to the syntax parser itself (Yacc_state),
      so that parsing multiple statements in stored programs can create multiple
      LEX structures while not changing the unique Yacc_state.
      
      Now, Yacc_state and the existing Lex_input_stream are aggregated into
      Parser_state, a structure that represent the complete state of the (Lexical +
      Syntax) parser.
      0816ee6d
    • Joerg Bruehe's avatar
      Merge main 5.0 into 5.0-build · 9a95278a
      Joerg Bruehe authored
      9a95278a
  12. 10 Jul, 2008 4 commits
  13. 09 Jul, 2008 6 commits
  14. 08 Jul, 2008 2 commits
  15. 07 Jul, 2008 3 commits
    • Marc Alff's avatar
      Merge · 68925ec2
      Marc Alff authored
      68925ec2
    • Marc Alff's avatar
      Bug#26030 (Parsing fails for stored routine w/multi-statement execution · f3ff1aeb
      Marc Alff authored
      enabled)
      
      Before this fix, the lexer and parser would treat the ';' character as a
      different token (either ';' or END_OF_INPUT), based on convoluted logic,
      which failed in simple cases where a stored procedure is implemented as a
      single statement, and used in a multi query.
      
      With this fix:
      - the character ';' is always parsed as a ';' token in the lexer,
      - parsing multi queries is implemented in the parser, in the 'query:' rules,
      - the value of thd->client_capabilities, which is the capabilities
        negotiated between the client and the server during bootstrap,
        is immutable and not arbitrarily modified during parsing (which was the
        root cause of the bug)
      f3ff1aeb
    • Mats Kindahl's avatar
      Bug #37150 Risk for crash in User_var_log_event::exec_event() · b9d6d4c0
      Mats Kindahl authored
      On certain kinds of errors (e.g., out of stack), a call to Item_func_
      set_user_var::fix_fields() might fail.  Since the return value of this
      call was not checked inside User_var_log_event::exec_event(), continuing
      execution after this will cause a crash inside Item_func_set_user_var::
      update_hash().
      
      The bug is fixed by aborting execution of the event with an error if
      fix_fields() fails, since it is not possible to continue execution anyway.
      b9d6d4c0
  16. 05 Jul, 2008 1 commit
  17. 04 Jul, 2008 2 commits