An error occurred fetching the project authors.
- 29 Mar, 2014 1 commit
-
-
Sergei Golubchik authored
MDEV-5971 Asymmetry between CAST(DATE'2001-00-00') to INT and TO CHAR in prepared statements Consistently set maybe_null flag, even not-NULL temporal literal may become NULL in the restrictive sql_mode.
-
- 26 Mar, 2014 1 commit
-
-
Sergei Golubchik authored
simplify the prototype and move it to sql_string.h
-
- 14 Mar, 2014 1 commit
-
-
unknown authored
MDEV-5446: Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' fails on EXPLAIN EXTENDED with VALUES function field_index should be set correctly for null field created by Item_insert_value::fix_fields().
-
- 07 Mar, 2014 1 commit
-
-
Sergei Golubchik authored
-
- 06 Mar, 2014 1 commit
-
-
Alexander Barkov authored
-
- 26 Feb, 2014 1 commit
-
-
unknown authored
Removed repetative calls of virtual functions. Removed check of posibility just copy field for every record.
-
- 19 Feb, 2014 1 commit
-
-
Sergey Vojtovich authored
This is port of fix for MySQL BUG#17647863. revno: 5572 revision-id: jon.hauglid@oracle.com-20131030232243-b0pw98oy72uka2sj committer: Jon Olav Hauglid <jon.hauglid@oracle.com> timestamp: Thu 2013-10-31 00:22:43 +0100 message: Bug#17647863: MYSQL DOES NOT COMPILE ON OSX 10.9 GM Rename test() macro to MY_TEST() to avoid conflict with libc++.
-
- 12 Feb, 2014 1 commit
-
-
Sergei Golubchik authored
fix the NAME_CONST check to only allow literals, negated literals, and literals with the explicit collation.
-
- 11 Feb, 2014 1 commit
-
-
Michael Widenius authored
Problem was that we used cache_table in some cases where it was not initialized mysql-test/r/func_group.result: Added test case mysql-test/t/func_group.test: Added test case sql/item.cc: Don't use cached_table if not set sql/item_sum.cc: Don't use cached_table
-
- 24 Jan, 2014 1 commit
-
-
Michael Widenius authored
Main fix was to not cache derivied tables as they may be temporary tables that are deleted before the next query. This was a bit tricky as Item_field::fix_fields depended on cached_tables to be set to resolve some columns. mysql-test/r/sp-bugs.result: Added test case mysql-test/t/sp-bugs.test: Added test case sql/item.cc: Fixed fix_outer_field to handle case where found field did not have in cached_table Idea is that if cached_table is not avaliable, use from_field->table->pos_in_table_list instead sql/records.cc: Also accept INTERNAL_TMP_TABLE for memmap sql/sql_base.cc: More DBUG_PRINT Fixed that setup_natural_join_row_types() is not run twice. Original code modified context->first_name_resolution_table also for second executions. This was wrong as this could give wrong results if some joins had been optimized away between calls. sql/sql_derived.cc: Mark derived tables as internal temporary tables (INTERNAL_TMP_TABLE), not as NON_TRANSACTIONAL_TMP_TABLE. This is more correct as the tables are not visible by the end user. sql/sql_insert.cc: Reset pos_in_table_list before calling fix_fields. One of the consequences of the change of not caching all generated tables in Item_ident is that pos_in_table_list needs to be correct in calls to fix_fields. sql/sql_lex.cc: More DBUG_PRINT sql/sql_parse.cc: Don't cache derivied tables as they may be temporary tables that are deleted before the next query sql/sql_select.cc: Reset table_vector. This was required as some code checked the vector to see if temporary tables had already been created. sql/table.cc: Mark tables with field translations as cacheable (as these will not disapper between stmt executions.
-
- 28 Nov, 2013 1 commit
-
-
Sergei Golubchik authored
fix the code to compile with clang. fix warnings too. include/probes_mysql_nodtrace.h: clang++ doesn't like numeric _constants_ being used in || (it suspects that the intention was | ). Boolean constants are ok. sql/hostname.cc: only used in DBUG_ASSERT sql/item.cc: str_to_time and str_to_datetime return bool, not MYSQL_TIMESTAMP_xxx sql/item_func.cc: str_to_datetime_with_warn() returns bool, not MYSQL_TIMESTAMP_xxx storage/cassandra/CMakeLists.txt: CMAKE_CXX_FLAGS can be empty storage/connect/odbconn.cpp: HWND is void* storage/connect/user_connect.h: deprecated on FreeBSD and unused anyway storage/connect/value.cpp: bad characters inside. unused. storage/spider/spd_trx.cc: clang++ warns that memset will also overwrite vtbl. it might be as well a good idea, as it asserts that the object will only be used as a storage. silence the warning.
-
- 21 Nov, 2013 1 commit
-
-
Alexander Barkov authored
Fixed.
-
- 08 Nov, 2013 1 commit
-
-
Alexander Barkov authored
-
- 04 Oct, 2013 1 commit
-
-
Igor Babaev authored
For aggregated fields from views/derived tables the possible adjustment of thd->lex->in_sum_func->max_arg_level in the function Item_field::fix_fields must be done before we leave the function.
-
- 25 Sep, 2013 1 commit
-
-
unknown authored
Other fix of maybe_null problem and revert of revno: 3608 "MDEV-3873 & MDEV-3876 & MDEV-3912 : Wrong result (extra rows) with ALL subquery from a MERGE view."
-
- 13 Sep, 2013 1 commit
-
-
Alexander Barkov authored
-
- 12 Sep, 2013 1 commit
-
-
Alexander Barkov authored
-
- 12 Aug, 2013 2 commits
-
-
Sergei Golubchik authored
* use sql_mode_for_dates() where appropriate. * always specify an argument for sql_mode_for_dates() (future-proof. easier to notice and fix if the caller will start using thd from a local variable or an argument)
-
Alexander Barkov authored
-
- 15 Jul, 2013 1 commit
-
-
Sergei Golubchik authored
Includes 5.6 changesets for: ***** Fix for BUG#13489996 valgrind:conditional jump or move depends on uninitialised values-field_blob. blob_ptr_size was not initialized properly: remove this variable. ***** Bug#14021323 CRASH IN FIELD::SET_NULL WHEN INSERTING ROWS TO NEW TABLE *****
-
- 10 Jul, 2013 2 commits
-
-
Alexander Barkov authored
added: mysql-test/r/temporal_literal.result mysql-test/t/temporal_literal.test modified: client/mysqlbinlog.cc include/my_time.h mysql-test/r/cast.result mysql-test/r/partition_innodb.result mysql-test/t/cast.test mysql-test/t/partition_innodb.test sql-common/my_time.c sql/field.cc sql/item.cc sql/item.h sql/item_cmpfunc.cc sql/item_create.cc sql/item_create.h sql/item_strfunc.cc sql/item_timefunc.cc sql/item_timefunc.h sql/sql_select.cc sql/sql_time.cc sql/sql_time.h sql/sql_yacc.yy storage/spider/spd_db_mysql.cc
-
Alexander Barkov authored
TIME, DATETIME, TIMESTAMP added: mysql-test/r/type_temporal_mysql56.result mysql-test/std_data/mysql56datetime.MYD mysql-test/std_data/mysql56datetime.MYI mysql-test/std_data/mysql56datetime.frm mysql-test/std_data/mysql56time.MYD mysql-test/std_data/mysql56time.MYI mysql-test/std_data/mysql56time.frm mysql-test/std_data/mysql56timestamp.MYD mysql-test/std_data/mysql56timestamp.MYI mysql-test/std_data/mysql56timestamp.frm mysql-test/suite/rpl/r/rpl_temporal_mysql56.result mysql-test/suite/rpl/t/rpl_temporal_mysql56.test mysql-test/t/type_temporal_mysql56.test sql/compat56.cc sql/compat56.h modified: client/mysqlbinlog.cc include/my_time.h include/mysql.h.pp include/mysql_com.h mysql-test/r/statistics.result mysql-test/r/strict.result mysql-test/suite/binlog/r/binlog_mysqlbinlog_row_innodb.result mysql-test/suite/binlog/r/binlog_mysqlbinlog_row_myisam.result sql-common/my_time.c sql/CMakeLists.txt sql/field.cc sql/field.h sql/item.cc sql/item_strfunc.cc sql/item_sum.cc sql/item_timefunc.cc sql/log_event.cc sql/opt_range.cc sql/opt_table_elimination.cc sql/protocol.cc sql/rpl_utility.cc sql/rpl_utility.h sql/sql_partition.cc sql/sql_prepare.cc sql/sql_select.cc sql/sql_table.cc sql/table.cc storage/perfschema/pfs_engine_table.cc
-
- 03 Jul, 2013 1 commit
-
-
Sergei Golubchik authored
Cleanup: remove TIME_FUZZY_DATE. Introduce TIME_FUZZY_DATES which means "very fuzzy, the resulting value is only used for comparison. It can be invalid date, fine, as long as it can be compared". Updated many tests results (they're better now).
-
- 02 Jul, 2013 1 commit
-
-
Michael Widenius authored
-
- 15 Jun, 2013 1 commit
-
-
Michael Widenius authored
-
- 08 May, 2013 1 commit
-
-
Alexander Barkov authored
MDEV-4489 "Replication of big5, cp932, gbk, sjis strings makes wrong values on slave" has been fixed. Problem: String constants of some Asian charsets (big5,cp932,gbk,sjis) can have backslash '\' (0x5C) in the second byte of multi-byte characters. Replicating of such constants using the standard '\'-escaping is dangerous. Therefore, constants of these charsets are replicated using hex notation: INSERT INTO t1 (a) VALUES (0x815C); However, 0xHHHH constants do not work well in some cases, because they can behave as strings and as numbers, depending on context (for example, depending on the data type of the column in an INSERT statement). This SQL script was not replicated correctly with statement-based replication: SET NAMES gbk; PREPARE STMT FROM 'INSERT INTO t1 (a) VALUES (?)'; SET @A = '1'; EXECUTE STMT USING @A; The INSERT statement was replicated as: INSERT INTO t1 (a) VALUES (0x31); '1' was correctly converted to the number 1 on master. But the 0x31 constant was treated as number 49 on slave. Fix: 1. Binary log now uses X'HHHH' instead of 0xHHHH constants. 2. The X'HHHH' constants now work always as strings, in all contexts. This is the SQL standard compliant behaviour. After the fix, the above statement is replicated as: INSERT INTO t1 (a) VALUES (X'31'); X'31' is treated as string '1' on slave, and is correctly converted to 1. modified: @ mysql-test/r/ctype_cp932_binlog_stm.result @ mysql-test/r/select.result @ mysql-test/r/select_jcl6.result @ mysql-test/r/select_pkeycache.result @ mysql-test/r/user_var-binlog.result @ mysql-test/r/varbinary.result @ mysql-test/suite/binlog/r/binlog_stm_ctype_ucs.result @ mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result @ mysql-test/suite/rpl/r/rpl_charset_sjis.result @ mysql-test/suite/rpl/r/rpl_mdev382.result @ mysql-test/suite/rpl/t/rpl_charset_sjis.test @ mysql-test/t/ctype_cp932_binlog_stm.test @ mysql-test/t/select.test @ mysql-test/t/varbinary.test Adding and updating tests @ sql/item.cc @ sql/item.h @ sql/sql_yacc.yy @ sql/sql_lex.cc Splitting the implementations of X'HH' and 0xHH constants into two separate classes. Fixing the parser to distinguish the two syntaxes. @ sql/log_event.cc Using X'HH' instead of 0xHH for binary logging for string constants of the "dangerous" charsets. @ sql/sql_string.h Adding a helped method String::append_hex().
-
- 17 Apr, 2013 1 commit
-
-
Sergei Golubchik authored
with a bit of lame protection against abuse.
-
- 12 Apr, 2013 1 commit
-
-
Alexey Botchkov authored
The patch contributed by Konstantin Osipov applied. Native comments: Implement multiple user-level locks per connection. GET_LOCK() function in MySQL allows a connection to hold at most one user level lock. Taking a new lock automatically releases the old lock, if any. The limit of one lock per session existed since early versions of MySQL didn't have a deadlock detector for SQL locks. MDL patches in MySQL 5.5 added a deadlock detector, so starting from 5.5 it became possible to take multiple locks in any order -- a deadlock, should it occur, would be detected and an error returned to the client which closed the wait chain. This is exactly what is done in this patch: ULLs are moved to use MDL subsystem.
-
- 07 Apr, 2013 1 commit
-
-
Sergei Golubchik authored
and sometimes harmful (used with expressions)
-
- 29 Mar, 2013 1 commit
-
-
Vladislav Vaintroub authored
-
- 28 Mar, 2013 1 commit
-
-
Nisha Gopalakrishnan authored
REGULAR SQL VS PREPARED STATEMENT Analysis: --------- When passing user variables as parameters to the prepared statements, the IF() function evaluation turns out to be incorrect. Consider the example: SET @var1='0.038687'; SELECT @var1 , IF( @var1 = 0 , 1 ,@var1 ) AS sqlif ; +----------+----------+ | @var1 | sqlif | +----------+----------+ | 0.038687 | 0.038687 | +----------+----------+ Executing a prepared statement where the parameters are supplied: PREPARE fail_stmt FROM "SELECT ? , IF( ? = 0 , 1 , ? ) AS ps_if_fail" ; EXECUTE fail_stmt USING @var1 ,@var1 , @var1 ; +----------+------------+ | ? | ps_if_fail | +----------+------------+ | 0.038687 | 1 | +----------+------------+ 1 row in set (0.00 sec) In the regular statement or while executing the prepared statements without passing parameters, the decimal precision is set for the user variable of type string. The comparison function used for evaluation considered the precision while comparing the values. But while executing the prepared statement with the parameters supplied, the decimal precision was not set. Thus the comparison function chosen was different which looked at the absolute values for comparison. Fix: ---- The fix is to set 'decimals' field of Item_param to the default value which is nothing but the maximum number of decimals(NOT_FIXED_DEC). This is set for cases where the strings are converted to the numeric form within certain functions. Thus the value is not rounded off during comparison, ensuring correct evaluation.
-
- 25 Mar, 2013 1 commit
-
-
Michael Widenius authored
-
- 17 Mar, 2013 2 commits
-
-
Sergei Golubchik authored
Flip the switch and create Item_cache based on the argument's cmp_type, not argument's result_type(). Fix subselect_engine to calculate cmp_type correctly sql/item_subselect.h: mdev:4284
-
Sergei Golubchik authored
MDEV-4281 Assertion `maybe_null && item->null_value' fails in make_sortkey on CASE with different return types, GROUP_CONCAT, GROUP BY Fix Item::get_date() to mark the item NULL when returning an error.
-
- 25 Feb, 2013 1 commit
-
-
unknown authored
-
- 23 Jan, 2013 1 commit
-
-
Gleb Shchepa authored
Some queries with the "SELECT ... FROM DUAL" nested subqueries failed with an assertion on debug builds. Non-debug builds were not affected. There were a few different issues with similar assertion failures on different queries: 1. The first problem was related to the incomplete propagation of the "non-constant" item status from underlying subquery items to the outer item tree: in some cases non-constants were interpreted as constants and evaluated at the preparation stage (val_int() calls withing fix_fields() etc). Thus, the default implementation of Item_ref::const_item() from the Item parent class didn't take into account the "const_item" status of the referenced item tree -- it used the insufficient "used_tables() == 0" check instead. This worked in most cases since our "non-constant" functions like RAND() and SLEEP() set the RAND_TABLE_BIT in the used table map, so they aren't non-constant from Item_ref's "point of view". However, the "SELECT ... FROM DUAL" subquery may have an empty map of used tables, but at the same time subqueries are never "constant" at the context analysis stage (preparation, view creation etc). So, the non-contantness of such subqueries was missed. Fix: the Item_ref::const_item() function has been overloaded to take into account both (*ref)->const_item() status and tricky Item_ref::used_tables() return values, since the only (*ref)->const_item() call is not enough there. 2. In some cases instead of the const_item() call we check a value of the Item::with_subselect field to recognize items with nested subqueries. However, the Item_ref class didn't propagate this value from the referenced item tree. Fix: Item::has_subquery() and Item_ref::has_subquery() functions have been backported from 5.6. All direct references to the with_subselect fields of nested items have been with the has_subquery() function call. 3. The Item_func_regex class didn't propagate with_subselect as well, since it overloads the Item_func::fix_fields() function with insufficient fix_fields() implementation. Fix: the Item_func_regex::fix_fields() function has been modified to gather "constant" statuses from inner items. 4. The Item_func_isnull::update_used_tables() function has a special branch for the underlying item where the maybe_null value is false: in this case it marks the Item_func_isnull as a "const_item" and sets the cached_value to false. However, the Item_func_isnull::val_int() was not in sync with update_used_tables(): it didn't take into account neither const_item_cache nor cached_value for the case of "args[0]->maybe_null == false optimization". As far as such an Item_func_isnull has "const_item() == true", it's ok to call Item_func_isnull::val_int() etc from outer items on preparation stage. In this case the server tried to call Item_func_isnull::args[0]->isnull(), and if the args[0] item contained a nested not-nullable subquery, it failed with an assertion. Fix: take the value of Item_func_isnull::const_item_cache into account in the val_int() function. 5. The auxiliary Item_is_not_null_test class has a similar optimization in the update_used_tables() function as the Item_func_isnull class has, and the same issue in the val_int() function. In addition to that the Item_is_not_null_test::update_used_tables() doesn't update the const_item_cache value, so the "maybe_null" optimization is useless there. Thus, we missed some optimizations of cases like these (before and after the fix): < <is_not_null_test>(a), --- > <cache>(<is_not_null_test>(a)), or < having (<is_not_null_test>(a) and <is_not_null_test>(a)) --- > having 1 etc. Fix: update Item_is_not_null_test::const_item_cache in update_used_tables() and take in into account in val_int().
-
- 17 Jan, 2013 2 commits
-
-
Michael Widenius authored
This fixed failing test in group_by.test mysql-test/r/join_outer.result: Updated test case mysql-test/r/join_outer_jcl6.result: Updated test case sql/item.cc: Don't reset maybe_null in update_used_tables(); This breaks ROLLUP sql/item.h: Don't reset maybe_null in update_used_tables(); This breaks ROLLUP sql/item_cmpfunc.h: Don't reset maybe_null in update_used_tables(); This breaks ROLLUP
-
unknown authored
Don't reset maybe_null in update_used_tables(); This breaks ROLLUP This fixed failing test in group_by.test
-
- 07 Jan, 2013 1 commit
-
-
Sergei Golubchik authored
-
- 28 Dec, 2012 1 commit
-
-
unknown authored
from a MERGE view. The problem was in the lost ability to be null for the table of a left join if it is a view/derived table. It hapenned because setup_table_map(), was called earlier then we merged the view or derived. Fixed by propagating new maybe_null flag during Item::update_used_tables(). Change in join_outer.test and join_outer_jcl6.test appeared because IS NULL reported no used tables (i.e. constant) for argument which could not be NULL and new maybe_null flag was propagated for IS NULL argument (Item_field) because table the Item_field belonged to changed its maybe_null status.
-