An error occurred fetching the project authors.
- 08 May, 2007 4 commits
-
-
thek@adventure.(none) authored
into adventure.(none):/home/thek/Development/cpp/bug27792/my51-bug27792
-
thek@adventure.(none) authored
-
thek@adventure.(none) authored
into adventure.(none):/home/thek/Development/cpp/bug27792/my50-bug27792
-
thek@adventure.(none) authored
- Queries in the query cache are identified by the individual characters in the query statement, the current database and the current environment expressed as a set of system variable flags. - Since the set of environment flags didn't properly describe the current environment unexpected results were returned from the query cache. - Query cache is now cleared when the variable ft_boolean_syntax is updated. - An identification flag for the variable default_week_format is added to the query cache record. Thanks to Martin Friebe who has supplied significant parts of this patch.
-
- 30 Apr, 2007 2 commits
-
-
malff/marcsql@weblab.(none) authored
-
malff/marcsql@weblab.(none) authored
into weblab.(none):/home/marcsql/TREE/mysql-5.1-21513
-
- 27 Apr, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
Before this fix, the parser would sometime change where a token starts by altering Lex_input_string::tok_start, which later confused the code in sql_yacc.yy that needs to capture the source code of a SQL statement, like to represent the body of a stored procedure. This line of code in sql_lex.cc : case MY_LEX_USER_VARIABLE_DELIMITER: lip->tok_start= lip->ptr; // Skip first ` would <skip the first back quote> ... and cause the bug reported. In general, the responsibility of sql_lex.cc is to *find* where token are in the SQL text, but is *not* to make up fake or incomplete tokens. With a quoted label like `my_label`, the token starts on the first quote. Extracting the token value should not change that (it did). With this fix, the lexical analysis has been cleaned up to not change lip->tok_start (in the case found for this bug). The functions get_token() and get_quoted_token() now have an extra parameters, used when some characters from the beginning of the token need to be skipped when extracting a token value, like when extracting 'AB' from '0xAB', for example, for a HEX_NUM token. This exposed a bad assumption in Item_hex_string and Item_bin_string, which has been fixed: The assumption was that the string given, 'AB', was in fact preceded in memory by '0x', which might be false (it can be preceded by "x'" and followed by "'" -- or not be preceded by valid memory at all) If a name is needed for Item_hex_string or Item_bin_string, the name is taken from the original and true source code ('0xAB'), and assigned in the select_item rule, instead of relying on assumptions related to how memory is used.
-
- 26 Apr, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
-
- 25 Apr, 2007 2 commits
-
-
malff/marcsql@weblab.(none) authored
into weblab.(none):/home/marcsql/TREE/mysql-5.1-25411_merge
-
malff/marcsql@weblab.(none) authored
-
- 24 Apr, 2007 2 commits
-
-
malff/marcsql@weblab.(none) authored
into weblab.(none):/home/marcsql/TREE/mysql-5.0-25411_d
-
malff/marcsql@weblab.(none) authored
The issue found with bug 25411 is due to the function skip_rear_comments() which damages the source code while implementing a work around. The root cause of the problem is in the lexical analyser, which does not process special comments properly. For special comments like : [1] aaa /*!50000 bbb */ ccc since 5.0 is a version older that the current code, the parser is in lining the content of the special comment, so that the query to process is [2] aaa bbb ccc However, the text of the query captured when processing a stored procedure, stored function or trigger (or event in 5.1), can be after rebuilding it: [3] aaa bbb */ ccc which is wrong. To fix bug 25411 properly, the lexical analyser needs to return [2] when in lining special comments. In order to implement this, some preliminary cleanup is required in the code, which is implemented by this patch. Before this change, the structure named LEX (or st_lex) contains attributes that belong to lexical analysis, as well as attributes that represents the abstract syntax tree (AST) of a statement. Creating a new LEX structure for each statements (which makes sense for the AST part) also re-initialized the lexical analysis phase each time, which is conceptually wrong. With this patch, the previous st_lex structure has been split in two: - st_lex represents the Abstract Syntax Tree for a statement. The name "lex" has not been changed to avoid a bigger impact in the code base. - class lex_input_stream represents the internal state of the lexical analyser, which by definition should *not* be reinitialized when parsing multiple statements from the same input stream. This change is a pre-requisite for bug 25411, since the implementation of lex_input_stream will later improve to deal properly with special comments, and this processing can not be done with the current implementation of sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer. This change set alone does not fix bug 25411.
-
- 21 Apr, 2007 6 commits
-
-
mjorgensen@blade09.mysql.com authored
into blade09.mysql.com:/tmp/mmj/mysql-5.0-runtime
-
mjorgensen@blade09.mysql.com authored
into blade09.mysql.com:/tmp/mmj/mysql-5.1-runtime
-
holyfoot/hf@mysql.com/hfmain.(none) authored
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/d2/hf/mrg/mysql-5.1-opt
-
ibabaev@bk-internal.mysql.com authored
into bk-internal.mysql.com:/data0/bk/mysql-5.1-opt
-
igor@olga.mysql.com authored
-
- 20 Apr, 2007 20 commits
-
-
malff/marcsql@weblab.(none) authored
-
ibabaev@bk-internal.mysql.com authored
into bk-internal.mysql.com:/data0/bk/mysql-5.0-opt
-
malff/marcsql@weblab.(none) authored
into weblab.(none):/home/marcsql/TREE/mysql-5.0-rt-merge
-
malff/marcsql@weblab.(none) authored
into weblab.(none):/home/marcsql/TREE/mysql-5.1-rt-merge
-
evgen@moonbone.local authored
into moonbone.local:/mnt/gentoo64/work/bk-trees/mysql-5.1-opt
-
tomas@whalegate.ndb.mysql.com authored
into whalegate.ndb.mysql.com:/home/tomas/mysql-5.1
-
mats@romeo.(none) authored
-
mats@romeo.(none) authored
-
gshchepa/uchum@gshchepa.loc authored
into gshchepa.loc:/home/uchum/work/bk-trees/mysql-5.0-opt-27704
-
gshchepa/uchum@gshchepa.loc authored
into gshchepa.loc:/home/uchum/work/bk-trees/mysql-5.0-opt-27704
-
gshchepa/uchum@gshchepa.loc authored
Support for NULL components was incomplete for row comparison, fixed. Added support for abort_on_null at compare_row() like in 5.x
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B27786-5.0-opt
-
mhansson@dl145s.mysql.com authored
This bug was intruduced by the fix for bug#17212 (in 4.1). It is not ok to call test_if_skip_sort_order since this function will alter the execution plan. By contract it is not ok to call test_if_skip_sort_order in this context. This bug appears only in the case when the optimizer has chosen an index for accessing a particular table but finds a covering index that enables it to skip ORDER BY. This happens in test_if_skip_sort_order.
-
mats@romeo.(none) authored
into romeo.(none):/home/bk/merge-mysql-5.1
-
mats@romeo.(none) authored
into romeo.(none):/home/bk/merge-mysql-5.1
-
mats@romeo.(none) authored
into romeo.(none):/home/bk/merge-mysql-5.0
-
mats@romeo.(none) authored
into romeo.(none):/home/bkroot/mysql-5.0-rpl
-
mats@romeo.(none) authored
into romeo.(none):/home/bk/b27779-mysql-5.1-rpl
-
mats@romeo.(none) authored
-
gkodinov/kgeorge@magare.gmz authored
When merging views into the enclosing statement the ORDER BY clause of the view is merged to the parent's ORDER BY clause. However when the VIEW is merged into an UNION branch the ORDER BY should be ignored. Use of ORDER BY for individual SELECT statements implies nothing about the order in which the rows appear in the final result because UNION by default produces unordered set of rows. Fixed by ignoring the ORDER BY clause from the merge view when expanded in an UNION branch.
-
- 19 Apr, 2007 2 commits
-
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B27530-5.0-opt
-
gluh@mysql.com/eagle.(none) authored
They can drop table after table names list creation and before table opening. We open non existing table and get ER_NO_SUCH_TABLE error. In this case we do not store the record into I_S table and clear error.
-