1. 16 Jul, 2008 1 commit
  2. 15 Jul, 2008 4 commits
  3. 14 Jul, 2008 4 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
    • Ramil Kalimullin's avatar
      auto-merge · bbecb196
      Ramil Kalimullin authored
      bbecb196
    • Gleb Shchepa's avatar
      Bug #37761: IN handles NULL differently for table-subquery · 211164ff
      Gleb Shchepa authored
                  and value-list
      
      The server returns unexpected results if a right side of the 
      NOT IN clause consists of NULL value and some constants of
      the same type, for example:
      
        SELECT * FROM t WHERE NOT t.id IN (NULL, 1, 2) 
        
      may return 3, 4, 5 etc if a table contains these values.
      
      
      The Item_func_in::val_int method has been modified:
      unnecessary resets of an Item_func_case::has_null field 
      value has been moved outside of an argument comparison
      loop. (Also unnecessary re-initialization of the null_value
      field has been moved).
      211164ff
  4. 11 Jul, 2008 1 commit
  5. 10 Jul, 2008 9 commits
  6. 09 Jul, 2008 9 commits
  7. 08 Jul, 2008 6 commits
  8. 07 Jul, 2008 6 commits
    • Mattias Jonsson's avatar
    • Marc Alff's avatar
      Manual merge of bug#26030 in mysql-5.1-bugteam · 8454773a
      Marc Alff authored
      8454773a
    • Mattias Jonsson's avatar
      merge · 6cc1fcc9
      Mattias Jonsson authored
      6cc1fcc9
    • Mattias Jonsson's avatar
      Bug#35745: SELECT COUNT(*) is not correct for some partitioned tables. · c499df92
      Mattias Jonsson authored
      problem was that ha_partition::records was not implemented, thus
      using the default handler::records, which is not correct if the engine
      does not support HA_STATS_RECORDS_IS_EXACT.
      Solution was to implement ha_partition::records as a wrapper around
      the underlying partitions records.
      
      The rows column in explain partitions will now include the total
      number of records in the partitioned table.
      
      (recommit after removing out-commented code)
      c499df92
    • 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