- 15 Jul, 2008 3 commits
-
-
Gleb Shchepa authored
-
Gleb Shchepa authored
Note: item->null_value is not updated before a call to item->store(), item->is_null() is not too (in common case).
-
Marc Alff authored
-
- 14 Jul, 2008 4 commits
-
-
Marc Alff authored
-
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.
-
Ramil Kalimullin authored
-
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).
-
- 11 Jul, 2008 1 commit
-
-
Horst Hunger authored
-
- 10 Jul, 2008 9 commits
-
-
Gleb Shchepa authored
-
Gleb Shchepa authored
-
Gleb Shchepa authored
-
Gleb Shchepa authored
-
Marc Alff authored
-
Tatiana A. Nurnberg authored
-
Tatiana A. Nurnberg authored
-
Tatiana A. Nurnberg authored
offset for time part in UUIDs was 1/1000 of what it should be. In other words, offset was off. Also handle the case where we count into the future when several UUIDs are generated in one "tick", and then the next call is late enough for us to unwind some but not all of those borrowed ticks. Lastly, handle the case where we keep borrowing and borrowing until the tick-counter overflows by also changing into a new "numberspace" by creating a new random suffix.
-
Tatiana A. Nurnberg authored
offset for time part in UUIDs was 1/1000 of what it should be. In other words, offset was off. Also handle the case where we count into the future when several UUIDs are generated in one "tick", and then the next call is late enough for us to unwind some but not all of those borrowed ticks. Lastly, handle the case where we keep borrowing and borrowing until the tick-counter overflows by also changing into a new "numberspace" by creating a new random suffix.
-
- 09 Jul, 2008 9 commits
-
-
Gleb Shchepa authored
-
Gleb Shchepa authored
-
Gleb Shchepa authored
-
Matthias Leich authored
-
Mattias Jonsson authored
-
Ramil Kalimullin authored
Problem: reading/writing data from/to an address without proper alignment leads to SIGBUS on some platforms. Fix: use the correct data type when dereferencing variable values.
-
Matthias Leich authored
"funcs_2: The tests do not check if optional character sets exist." 2. Minor cleanup
-
Mattias Jonsson authored
The problem is that relying on the output of the 'ls' command is not portable as its behavior is not the same between systems and it might even not be available at all in (Windows). So I added list_files that relies on the portable mysys library instead. (and also list_files_write_file and list_files_append_file, since the test was using '--exec ls' in that way.)
-
kent@mysql.com authored
-
- 08 Jul, 2008 6 commits
-
-
Marc Alff authored
-
Marc Alff authored
-
Marc Alff authored
Fixed the test to expect the correct result. The previous test script was in fact affected by 26030, and wrongly expected a ER_PARSE_ERROR error.
-
Jonathan Perkin authored
-
Mats Kindahl authored
-
Mats Kindahl authored
-
- 07 Jul, 2008 8 commits
-
-
Mattias Jonsson authored
-
Marc Alff authored
-
Mattias Jonsson authored
-
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)
-
Marc Alff authored
-
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)
-
Georgi Kodinov authored
- moved the test into a separate file to check for presence of the test variable
-
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.
-