- 24 Nov, 2007 1 commit
-
-
unknown authored
into mysql.com:/home/hf/work/30284/my50-30284 myisam/mi_check.c: Auto merged mysql-test/t/gis.test: Auto merged mysql-test/r/gis.result: SCCS merged
-
- 19 Nov, 2007 1 commit
-
-
unknown authored
SPATIAL key is fine actually, but the chk_key() function mistakenly returns error. It tries to compare checksums of btree and SPATIAL keys while the checksum for the SPATIAL isn't calculated (always 0). Same thing with FULLTEXT keys is handled using full_text_keys counter, so fixed by counting both SPATIAL and FULLTEXT keys in that counter. myisam/mi_check.c: Bug #30284 spatial key corruption full_text_keys counts both FULL_TEXT and SPATIAL keys mysql-test/r/gis.result: Bug #30284 spatial key corruption test result mysql-test/t/gis.test: Bug #30284 spatial key corruption. test case
-
- 16 Nov, 2007 4 commits
-
-
unknown authored
into polly.(none):/home/kaa/src/opt/mysql-5.0-opt sql/sql_select.cc: Auto merged
-
unknown authored
checked for each record' The problem was in incorrectly calculated length of the buffer used to store a hexadecimal representation of an index map in select_describe(). This could result in buffer overrun and stack corruption under some circumstances. Fixed by correcting the calculation. mysql-test/r/explain.result: Added a test case for bug #32241. mysql-test/t/explain.test: Added a test case for bug #32241. sql/sql_select.cc: Corrected the buffer length calculation. Count one hex digit as 4 bits, not 8.
-
unknown authored
into mysql.com:/home/gluh/MySQL/Merge/5.0-opt
-
unknown authored
Implement neccessary shared lock structure for table locks. This is the backport of bug26241 fix. sql/ha_blackhole.cc: Implement neccessary shared lock structure for table locks. sql/ha_blackhole.h: Declare shared structure for table locks sql/handler.cc: added BLACKHOLE_DB case
-
- 15 Nov, 2007 1 commit
-
-
unknown authored
into magare.gmz:/home/kgeorge/mysql/autopush/B31928-5.0-opt mysql-test/r/type_date.result: Auto merged mysql-test/t/type_date.test: Auto merged
-
- 14 Nov, 2007 4 commits
-
-
unknown authored
-
unknown authored
into mysql.com:/home/gluh/MySQL/Merge/5.0-opt
-
unknown authored
into mysql.com:/home/gluh/MySQL/Merge/5.0-opt mysql-test/t/subselect.test: Auto merged mysql-test/t/variables.test: Auto merged sql/item_func.cc: Auto merged sql/item_timefunc.cc: Auto merged mysql-test/r/select.result: manual merge mysql-test/t/select.test: manual merge
-
unknown authored
into mysql.com:/home/gluh/MySQL/Merge/4.1-opt
-
- 13 Nov, 2007 5 commits
-
-
unknown authored
into mysql.com:/home/hf/work/31305/my50-31305
-
unknown authored
into mysql.com:/home/hf/work/31305/my50-31305
-
unknown authored
into mysql.com:/home/hf/work/31305/my41-31305
-
unknown authored
into magare.gmz:/home/kgeorge/mysql/autopush/B31562-5.0-opt sql/item.cc: Auto merged sql/sql_select.cc: Auto merged
-
unknown authored
The columns in HAVING can reference the GROUP BY and SELECT columns. There can be "table" prefixes when referencing these columns. And these "table" prefixes in HAVING use the table alias if available. This means that table aliases are subject to the same storage rules as table names and are dependent on lower_case_table_names in the same way as the table names are. Fixed by : 1. Treating table aliases as table names and make them lowercase when printing out the SQL statement for view persistence. 2. Using case insensitive comparison for table aliases when requested by lower_case_table_names mysql-test/r/lowercase_view.result: Bug #31562: test case mysql-test/t/lowercase_view.test: Bug #31562: test case sql/item.cc: Bug #31562: lower_case_table_name contious comparison when searching in GROUP BY sql/sql_base.cc: Bug #31562: lower_case_table_name contious comparison when searching in SELECT sql/sql_select.cc: Bug #31562: treat table aliases as table names and make them lowercase when printing
-
- 12 Nov, 2007 10 commits
-
-
unknown authored
into mattiasj-laptop.(none):/home/mattiasj/clones/mysql-5.0-engines_with_main
-
unknown authored
into mattiasj-laptop.(none):/home/mattiasj/clones/mysql-5.0-engines_with_main
-
unknown authored
into mysql.com:/home/svoj/devel/mysql/BUG32111/mysql-5.0-engines mysql-test/r/symlink.result: Auto merged mysql-test/t/symlink.test: Auto merged
-
unknown authored
Use proper variable for test. mysql-test/t/symlink.test: Use proper variable for test. mysql-test/r/symlink.result: Use proper variable for test.
-
unknown authored
into mysql.com:/home/svoj/devel/mysql/BUG32111/mysql-5.0-engines mysql-test/r/symlink.result: Auto merged mysql-test/t/symlink.test: Auto merged mysys/my_symlink2.c: Auto merged
-
unknown authored
-
unknown authored
into mysql.com:/home/svoj/devel/mysql/BUG32111/mysql-4.1-engines mysys/my_symlink2.c: Auto merged mysql-test/r/symlink.result: SCCS merged mysql-test/t/symlink.test: SCCS merged
-
unknown authored
into polly.(none):/home/kaa/src/opt/mysql-5.0-opt sql/sql_select.cc: Auto merged mysql-test/r/select.result: Manual merge. mysql-test/t/select.test: Manual merge.
-
unknown authored
into mysql.com:/home/hf/work/31305/my50-31305 BitKeeper/etc/ignore: auto-union myisam/mi_dynrec.c: Auto merged
-
unknown authored
When we insert a record into MYISAM table which is almost 'full', we first write record data in the free space inside a file, and then check if we have enough space after the end of the file. So if we don't have the space, table will left corrupted. Similar error also happens when we updata MYISAM tables. Fixed by modifying write_dynamic_record and update_dynamic_record functions to check for free space before writing parts of a record BitKeeper/etc/ignore: Added libmysql_r/client_settings.h libmysqld/ha_blackhole.cc to the ignore list myisam/mi_dynrec.c: Bug #31305 myisam tables crash when they are near capacity. now we check space left in table in write_dynamic_record and update_dynamic_record functions. If we don't have enough room for the new (updated) record, return with the error. mysql-test/r/almost_full.result: New BitKeeper file ``mysql-test/r/almost_full.result'' mysql-test/t/almost_full.test: New BitKeeper file ``mysql-test/t/almost_full.test''
-
- 10 Nov, 2007 10 commits
-
-
unknown authored
into mysql.com:/misc/mysql/31700/50-31700 sql/sql_select.cc: Auto merged
-
unknown authored
into gleb.loc:/home/uchum/work/bk/5.0-opt
-
unknown authored
into gleb.loc:/home/uchum/work/bk/5.0-opt sql/item_cmpfunc.cc: Auto merged
-
unknown authored
into polly.(none):/home/kaa/src/opt/mysql-5.0-opt sql/sql_select.cc: Auto merged
-
unknown authored
After adding an index the <VARBINARY> IN (SELECT <BINARY> ...) clause returned a wrong result: the VARBINARY value was illegally padded with zero bytes to the length of the BINARY column for the index search. (<VARBINARY>, ...) IN (SELECT <BINARY>, ... ) clauses are affected too. sql/item.cc: Fixed bug #28076. The Item_cache_str::save_in_field method has been overloaded to check cached values for an illegal padding before the saving into a field. sql/item.h: Fixed bug #28076. The Item_cache_str::is_varbinary flag has been added and the Item_cache_str::save_in_field method has been overloaded to prevent cached values from an illegal padding when saving in fields. The signature of the Item_cache::get_cache method has been changed to accept pointers to Item instead of Item_result values. sql/item_cmpfunc.cc: Fixed bug #28076. The Item_in_optimizer::fix_left method has been modified to to call Item_cache::get_cache in a new manner. sql/item_subselect.cc: Fixed bug #28076. The subselect_indexsubquery_engine::exec method has been modified to take into account field conversion errors (copy&paste from subselect_uniquesubquery_engine::exec). sql/sp_rcontext.cc: Fixed bug #28076. The sp_rcontext::create_case_expr_holder method has been modified to call Item_cache::get_cache in a new manner. sql/sp_rcontext.h: Fixed bug #28076. The sp_rcontext::create_case_expr_holder method signature has been modified to pass Item pointers to the Item_cache::get_cache method. sql/sql_class.cc: Fixed bug #28076. The select_max_min_finder_subselect::send_data method has been modified to call Item_cache::get_cache in a new manner. mysql-test/t/subselect.test: Added test case for bug #28076. mysql-test/r/subselect.result: Added test case for bug #28076.
-
unknown authored
into mysql.com:/misc/mysql/31700/50-31700 sql/sql_select.cc: Auto merged
-
unknown authored
UNIQUE (eq-ref) lookups result in table being considered as a "constant" table. Queries that consist of only constant tables are processed in do_select() in a special way that doesn't invoke evaluate_join_record(), and therefore doesn't increase the counters join->examined_rows and join->thd->row_count. The patch increases these counters in this special case. NOTICE: This behavior seems to contradict what the documentation says in Sect. 5.11.4: "Queries handled by the query cache are not added to the slow query log, nor are queries that would not benefit from the presence of an index because the table has zero rows or one row." No test case in 5.0 as issue shows only in slow query log, and other counters can give subtly different values (with regard to counting in create_sort_index(), synthetic rows in ROLLUP, etc.). sql/sql_class.h: add documentation for some variables sql/sql_select.cc: Don't forget const tables when counting read records!
-
unknown authored
into mysql.com:/scratch/tnurnberg/31800/50-31800 mysql-test/r/select.result: Auto merged mysql-test/t/select.test: Auto merged
-
unknown authored
BETWEEN was more lenient with regard to what it accepted as a DATE/DATETIME in comparisons than greater-than and less-than were. ChangeSet makes < > comparisons similarly robust with regard to trailing garbage (" GMT-1") and "missing" leading zeros. Now all three comparators behave similarly in that they throw a warning for "junk" at the end of the data, but then proceed anyway if possible. Before < > fell back on a string- (rather than date-) comparison when a warning-condition was raised in the string-to-date conversion. Now the fallback only happens on actual errors, while warning- conditions still result in a warning being to delivered to the client. mysql-test/r/select.result: Show that we compare DATE/DATETIME-like strings as date(time)s now, rather than as bin-strings. Adjust older result as "2005-09-3a" is now correctly seen as "2005-09-3" + trailing garbage, rather than as "2005-09-30". mysql-test/t/select.test: Show that we compare DATE/DATETIME-like strings as date(time)s now, rather than as bin-strings. sql-common/my_time.c: correct/clarify date-related comments, particulary for check_date(). doxygenize comment while at it. sql/item_cmpfunc.cc: get_date_from_str() no longer signals an error when all we had was a warning-condition -- and one we already gave the user a warning for at that. Preamble doxygenized.
-
unknown authored
into mysql.com:/misc/mysql/31990/50-31990
-
- 09 Nov, 2007 3 commits
-
-
unknown authored
The bug is a regression introduced by the fix for bug30596. The problem was that in cases when groups in GROUP BY correspond to only one row, and there is ORDER BY, the GROUP BY was removed and the ORDER BY rewritten to ORDER BY <group_by_columns> without checking if the columns in GROUP BY and ORDER BY are compatible. This led to incorrect ordering of the result set as it was sorted using the GROUP BY columns. Additionaly, the code discarded ASC/DESC modifiers from ORDER BY even if its columns were compatible with the GROUP BY ones. This patch fixes the regression by checking if ORDER BY columns form a prefix of the GROUP BY ones, and rewriting ORDER BY only in that case, preserving the ASC/DESC modifiers. That check is sufficient, since the GROUP BY columns contain a unique index. mysql-test/r/group_by.result: Added a test case for bug #32202. mysql-test/t/group_by.test: Added a test case for bug #32202. sql/sql_select.cc: In cases when groups in GROUP BY correspond to only one row and there is ORDER BY, rewrite the query to ORDER BY <group_by_columns> only if the columns in ORDER BY and GROUP BY are compatible, i.e. either one forms a prefix for another.
-
unknown authored
into polly.(none):/home/kaa/src/opt/mysql-5.0-opt sql/sql_udf.cc: Auto merged
-
unknown authored
causes out of memory errors The code in mysql_create_function() and mysql_drop_function() assumed that the only reason for UDFs being uninitialized at that point is an out-of-memory error during initialization. However, another possible reason for that is the --skip-grant-tables option in which case UDF initialization is skipped and UDFs are unavailable. The solution is to check whether mysqld is running with --skip-grant-tables and issue a proper error in such a case. mysql-test/r/skip_grants.result: Added a test case for bug #32020. mysql-test/t/skip_grants.test: Added a test case for bug #32020. sql/sql_udf.cc: Issue a proper error when a user tries to CREATE/DROP a UDF on a server running with the --skip-grant-tables option.
-
- 08 Nov, 2007 1 commit
-
-
unknown authored
into polly.(none):/home/kaa/src/opt/mysql-5.0-opt
-