summaryrefslogtreecommitdiff
path: root/sql/item.cc
Commit message (Collapse)AuthorAgeFilesLines
* Fix for MDEV-18276, typo in error message + all other occurrences of referingChris Calender2019-03-231-1/+1
|
* Merge branch '10.1' into 10.2Sergei Golubchik2019-03-151-1/+4
|\
| * MDEV-16958 Assertion `field_length < 5' failed in Field_year::val_str or ↵Alexander Barkov2019-03-151-1/+4
| | | | | | | | data corruption upon SELECT with UNION and aggregate functions
* | MDEV-18431: Select max + row_number giving incorrect resultVarun Gupta2019-03-121-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | The issue here was when we had a subquery and a window function in an expression in the select list then subquery was getting computed after window function computation. This resulted in incorrect results because the subquery was correlated and the fields in the subquery was pointing to the base table instead of the temporary table. The approach to fix this was to have an additional field in the temporary table for the subquery and to execute the subquery before window function execution. After execution the values for the subquery were stored in the temporary table and then when we needed to calcuate the expression, all we do is read the values from the temporary table for the subquery.
* | Backporting MDEV-15597 Add class Load_data_outvar and avoid using ↵Alexander Barkov2019-02-231-0/+25
| | | | | | | | | | | | Item::STRING_ITEM for Item_user_var_as_out_param detection This is a part of "MDEV-18045 Backporting the MDEV-15497 changes to 10.2 branch"
* | Merge 10.1 into 10.2Marko Mäkelä2019-02-021-13/+6
|\ \ | |/
| * MDEV-18195 ASAN use-after-poison in my_strcasecmp_utf8 / Item::eq upon ↵Alexander Barkov2019-01-241-12/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | prepared statement with ORDER BY NAME_CONST ASAN noticed a freed memory access during EXECUTE in this script: PREPARE stmt FROM "SELECT 'x' ORDER BY NAME_CONST( 'f', 'foo' )"; EXECUTE stmt; In case of a PREPARE statement, all Items, including Item_name_const, are created on Prepared_statement::main_mem_root. Item_name_const::fix_fields() did not take this into account and could allocate the value of Item::name on a wrong memory root, in this code: if (is_autogenerated_name) { set_name(thd, item_name->c_ptr(), (uint) item_name->length(), system_charset_info); } When fix_fields() is called in the reported SQL script, THD's arena already points to THD::main_mem_root rather than to Prepared_statement::main_mem_root, so Item::name was allocated on THD::main_mem_root. Then, at the end of the dispatch_command() for the PREPARE statement, THD::main_mem_root got cleared. So during EXECUTE, Item::name pointed to an already freed memory. This patch changes the code to set the implicit name for Item_name_const at the constructor time rather than at fix_fields time. This guarantees that Item_name_const and its Item::name always reside on the same memory root. Note, this change makes the code for Item_name_const symmetric with other constant-alike items that set their default implicit names at the constructor call time rather than at fix_fields() time: - Item_string - Item_int - Item_real - Item_decimal - Item_null - Item_param
* | MDEV-15424: Unreasonable SQL Error (1356) on select from viewVarun Gupta2018-12-191-1/+3
| | | | | | | | | | | | | | | | While printing a view containing a window function we were printing it as an Item_field object instead of an Item_window_func object. This is incorrect and this leads to us throwing an error ER_VIEW_INVALID. Fixed by adjusting the Item_ref:print function. Also made UDF function aware if there arguments have window function.
* | MDEV-14576 Include full name of object in message about incorrect value for ↵Alexey Botchkov2018-12-161-1/+13
| | | | | | | | | | | | | | | | column. The error message modified. Then the TABLE_SHARE::error_table_name() implementation taken from 10.3, to be used as a name of the table in this message.
* | add more dbug helpers for gdbSergei Golubchik2018-12-121-0/+3
| |
* | MDEV-16217: Assertion `!table || (!table->read_set || ↵bb-10.2-MDEV-16217Oleksandr Byelkin2018-11-141-2/+23
| | | | | | | | | | | | | | | | | | bitmap_is_set(table->read_set, field_index))' failed in Field_num::get_date - clean up DEFAULT() to work only with default value and correctly print itself. - fix of DBUG_ASSERT about fields read/write - fix of field marking for write based really on the thd->mark_used_columns flag
* | MDEV-17574 SIGSEGV or Assertion `producing_item != __null' inIgor Babaev2018-11-081-3/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Item_direct_view_ref::derived_field_transformer_for_where upon updating a view The condition pushed into a materialized derived / view mast be adjusted for the new context: its column references must be substituted for references to the columns of the underlying tables if the condition is pushed into WHERE. The substitution is performed by the 'transform' method. If the materialized derived is used in a mergeable view then the references to the columns of the view are represented by Item_direct_view_ref objects. The transform method first processes the item wrapped in such an object and only after this it transforms the object itself. The transformation procedure of an Item_direct_view_ref object has to know whether the item it wraps has been substituted. If so the procedure does not have to do anything. In the code before this patch it was not possible for the transformation procedure used by an Item_direct_view_ref object to find out whether a substitution for the wrapped item had happened.
* | MDEV-17354 Server crashes in add_key_field / .. / ↵Igor Babaev2018-10-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Item_func_null_predicate::add_key_fields upon INSERT .. SELECT The function Item *Item_direct_view_ref::derived_field_transformer_for_where() erroneously did not strip off ref wrappers from references to materialized derived tables / views. As a result the expressions that contained some references of the type Item_direct_view_ref to columns of a materialized derived table / view V were pushed into V incorrectly. This could cause crashes for some INSERT ... SELECT statements.
* | Merge branch '10.1' into 10.2Sergei Golubchik2018-09-241-178/+2
|\ \ | |/
| * Merge branch '10.0' into 10.1Sergei Golubchik2018-09-231-178/+6
| |\
| | * Merge remote-tracking branch 'origin/5.5' into 10.0Alexander Barkov2018-09-211-177/+6
| | |\
| | | * MDEV-17250 Remove unused Item_copy_xxxAlexander Barkov2018-09-201-175/+0
| | | |
| | | * MDEV-17249 MAKETIME(-1e50,0,0) returns a wrong resultAlexander Barkov2018-09-201-2/+6
| | | |
* | | | MDEV-17154 Multiple selects from parametrized CTE fails with syntax errorIgor Babaev2018-09-141-1/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fills a serious flaw in the implementation of common table expressions. Before this patch an attempt to prepare a statement from a query with a parameter marker in a CTE that was used more than once in the query ended up with a bogus error message. Similarly if a statement in a stored procedure contained a CTE whose specification used a local variables and this CTE was referred to more than once in the statement then the server failed to execute the stored procedure returning a bogus error message on a non-existing field. The problems appeared due to incorrect handling of parameter markers / local variables in CTEs that were referred more than once. This patch fixes the problems by differentiating between the original occurrences of a parameter marker / local variable used in the specification of a CTE and the corresponding occurrences used in copies of this specification. These copies are substituted instead of non-first references to the CTE. The idea of the fix and even some code were taken from the MySQL implementation of the common table expressions.
* | | | Merge branch '10.1' into 10.2Oleksandr Byelkin2018-09-141-6/+4
|\ \ \ \ | |/ / /
| * | | Merge branch '11.0' into 10.1Oleksandr Byelkin2018-09-061-6/+4
| |\ \ \ | | |/ /
| | * | Merge branch '5.5' into 10.0bb-10.0-merge-sanjaOleksandr Byelkin2018-09-031-6/+4
| | |\ \ | | | |/
| | | * item_cmp_type: simplier for a faster codepathDaniel Black2018-08-221-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The common case for this function is that both types are the same. The Item_result defination from include/mysql.h.pp is the following enum enum Item_result { STRING_RESULT=0, REAL_RESULT, INT_RESULT, ROW_RESULT, DECIMAL_RESULT, TIME_RESULT }; The compilers aren't quite smart enough to optimize to this shortcut so this makes it quicker. Before the change: 0000000000012730 <item_cmp_type(Item_result, Item_result)>: 12730: 89 f0 mov %esi,%eax 12732: 09 f8 or %edi,%eax 12734: 74 4c je 12782 <item_cmp_type(Item_result, Item_result)+0x52> 12736: 83 ff 02 cmp $0x2,%edi 12739: 75 0a jne 12745 <item_cmp_type(Item_result, Item_result)+0x15> 1273b: b8 02 00 00 00 mov $0x2,%eax 12740: 83 fe 02 cmp $0x2,%esi 12743: 74 3c je 12781 <item_cmp_type(Item_result, Item_result)+0x51> 12745: 83 ff 03 cmp $0x3,%edi 12748: b8 03 00 00 00 mov $0x3,%eax 1274d: 74 32 je 12781 <item_cmp_type(Item_result, Item_result)+0x51> 1274f: 83 fe 03 cmp $0x3,%esi 12752: 74 2d je 12781 <item_cmp_type(Item_result, Item_result)+0x51> 12754: 83 ff 05 cmp $0x5,%edi 12757: b8 05 00 00 00 mov $0x5,%eax 1275c: 74 23 je 12781 <item_cmp_type(Item_result, Item_result)+0x51> 1275e: 83 fe 05 cmp $0x5,%esi 12761: 74 1e je 12781 <item_cmp_type(Item_result, Item_result)+0x51> 12763: 83 ff 04 cmp $0x4,%edi 12766: 74 05 je 1276d <item_cmp_type(Item_result, Item_result)+0x3d> 12768: 83 ff 02 cmp $0x2,%edi 1276b: 75 0f jne 1277c <item_cmp_type(Item_result, Item_result)+0x4c> 1276d: b8 04 00 00 00 mov $0x4,%eax 12772: 83 fe 02 cmp $0x2,%esi 12775: 74 0a je 12781 <item_cmp_type(Item_result, Item_result)+0x51> 12777: 83 fe 04 cmp $0x4,%esi 1277a: 74 05 je 12781 <item_cmp_type(Item_result, Item_result)+0x51> 1277c: b8 01 00 00 00 mov $0x1,%eax 12781: c3 retq 12782: 31 c0 xor %eax,%eax 12784: c3 retq After, noting the short cut and the beginning of the function: 0000000000012730 <item_cmp_type(Item_result, Item_result)>: 12730: 39 f7 cmp %esi,%edi 12732: 75 03 jne 12737 <item_cmp_type(Item_result, Item_result)+0x7> 12734: 89 f8 mov %edi,%eax 12736: c3 retq 12737: 83 ff 03 cmp $0x3,%edi 1273a: b8 03 00 00 00 mov $0x3,%eax 1273f: 74 32 je 12773 <item_cmp_type(Item_result, Item_result)+0x43> 12741: 83 fe 03 cmp $0x3,%esi 12744: 74 2d je 12773 <item_cmp_type(Item_result, Item_result)+0x43> 12746: 83 ff 05 cmp $0x5,%edi 12749: b8 05 00 00 00 mov $0x5,%eax 1274e: 74 23 je 12773 <item_cmp_type(Item_result, Item_result)+0x43> 12750: 83 fe 05 cmp $0x5,%esi 12753: 74 1e je 12773 <item_cmp_type(Item_result, Item_result)+0x43> 12755: 83 ff 04 cmp $0x4,%edi 12758: 74 05 je 1275f <item_cmp_type(Item_result, Item_result)+0x2f> 1275a: 83 ff 02 cmp $0x2,%edi 1275d: 75 0f jne 1276e <item_cmp_type(Item_result, Item_result)+0x3e> 1275f: b8 04 00 00 00 mov $0x4,%eax 12764: 83 fe 02 cmp $0x2,%esi 12767: 74 0a je 12773 <item_cmp_type(Item_result, Item_result)+0x43> 12769: 83 fe 04 cmp $0x4,%esi 1276c: 74 05 je 12773 <item_cmp_type(Item_result, Item_result)+0x43> 1276e: b8 01 00 00 00 mov $0x1,%eax 12773: c3 retq Signed-off-by: Daniel Black <daniel@linux.vnet.ibm.com>
* | | | Merge 10.1 into 10.2Marko Mäkelä2018-08-211-1/+1
|\ \ \ \ | |/ / /
| * | | Merge branch '10.0' into 10.1Oleksandr Byelkin2018-08-211-1/+1
| |\ \ \ | | |/ /
| | * | Merge branch '5.5' into 10.0Oleksandr Byelkin2018-08-151-1/+1
| | |\ \ | | | |/
| | | * MDEV-15475: Assertion `!table || (!table->read_set || ↵Oleksandr Byelkin2018-08-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | bitmap_is_set(table->read_set, field_index))' failed on EXPLAIN EXTENDED with constant table and view Print constant ISNULL value independent. Fix of printing of view FRM and CREATE VIEW output
* | | | Merge 10.1 into 10.2Marko Mäkelä2018-08-021-1/+2
|\ \ \ \ | |/ / /
| * | | Merge branch '10.0' into 10.1Oleksandr Byelkin2018-07-311-1/+2
| |\ \ \ | | |/ /
| | * | Merge 5.5 into 10.0Marko Mäkelä2018-07-301-1/+2
| | |\ \ | | | |/
| | | * Merge remote-tracking branch 'mysql/5.5' into 5.5Oleksandr Byelkin2018-07-291-1/+2
| | | |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We do not accept: 1. We did not have this problem (fixed earlier and better) d982e717aba67227ec40761a21a4211db91aa0e2 Bug#27510150: MYSQLDUMP FAILS FOR SPECIFIC --WHERE CLAUSES 2. We do not have such options (an DBUG_ASSERT put just in case) bbc2e37fe4e0ca3a7cfa1437a763dc43829e98e2 Bug#27759871: BACKRONYM ISSUE IS STILL IN MYSQL 5.7 3. Serg fixed it in other way in this release: e48d775c6f066add457fa8cfb2ebc4d5ff0c7613 Bug#27980823: HEAP OVERFLOW VULNERABILITIES IN MYSQL CLIENT LIBRARY
| | | | * Bug#27197235 USER VARIABLE + UINON + DECIMAL COLUMN RETURNSAjo Robert2018-04-101-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | WRONG VALUES User variables will have the default session collation associated with it. And a select which uses it as part of a union may infer the collation while type merging. This leads to problems when the result is of DECIMAL type. Setting the appropriate collation of DECIMAL result type is missing in 5.7 code base. Added code to set appropriate collation when the result is of DECIMAL type during Item_type_holder::join_types().
* | | | | Merge branch '10.1' into 10.2Sergei Golubchik2018-06-211-7/+21
|\ \ \ \ \ | |/ / / /
| * | | | MDEV-16190 Server crashes in Item_null_result::field_type on SELECT with ↵Alexander Barkov2018-06-111-7/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | time field, ROLLUP and HAVING virtual Item_null_result::get_date() was not overridden. It used the inherited Item::get_date(), which tests field_type(), which in case of Item_null_result calls result_field->field_type(), and result_field is not really always set (e.g. it's not set in the test case from the bug report). Overriding Item_null::get_date() like it's done for other val_xxx() methods. This make the code more symmetric across data types. In the new reduction, get_date() immediately returns NULL without entering into any data type specific code.
* | | | | MDEV-16386: Wrong result when pushdown into the HAVING clause of theGalina Shalygina2018-06-141-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | materialized derived table/view that uses aliases is done The problem appears when a column alias inside the materialized derived table/view t1 definition coincides with the column name used in the GROUP BY clause of t1. If the condition that can be pushed into t1 uses that ambiguous column name this column is determined as a column that is used in the GROUP BY clause instead of the alias used in the projection list of t1. That causes wrong result. To prevent it resolve_ref_in_select_and_group() was changed.
* | | | | Merge branch '10.1' into 10.2Sergei Golubchik2018-05-201-4/+4
|\ \ \ \ \ | |/ / / /
| * | | | Merge branch '10.0' into 10.1Sergei Golubchik2018-05-191-4/+4
| |\ \ \ \ | | |/ / /
| | * | | Merge branch '5.5' into 10.0Sergei Golubchik2018-05-191-4/+4
| | |\ \ \ | | | |/ /
| | | * | MDEV-15318 CREATE .. SELECT VALUES produces invalid table structureSergei Golubchik2018-05-171-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When Item_insert_value needs a dummy field, use zero-length Field_string, not Field_null. The latter isn't compatible with CREATE ... SELECT.
* | | | | MDEV-14750 Valgrind Invalid read, ASAN heap-use-after-free in ↵Sergei Golubchik2018-05-151-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Item_ident::print upon SHOW CREATE on partitioned table items in the partitioning function were taking the table name from the table's field (in set_field(from_field) in Item_field::fix_fields) and field's table_name is TABLE::alias. But alias is changed for every statement, and can be realloced if next statement uses a longer alias. But partitioning items are fixed once and live as long as the TABLE does. So if an alias is realloced, pointers to the old alias string will become invalid. Fix partitioning item table_name to point to the actual table name instead.
* | | | | cleanup: vcol_in_partition_func_processorSergei Golubchik2018-05-151-8/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | rename to post_fix_fields_part_expr_processor() because it's only used after fix_fields in fix_fields_part_func() and can be used for various post-fix_fields fixups
* | | | | Merge branch '10.1' into 10.2Sergei Golubchik2018-05-101-1/+9
|\ \ \ \ \ | |/ / / /
| * | | | Merge branch '10.0' into 10.1Sergei Golubchik2018-05-051-1/+9
| |\ \ \ \ | | |/ / /
| | * | | Merge branch '5.5' into 10.0Sergei Golubchik2018-04-291-0/+7
| | |\ \ \ | | | |/ /
| | | * | MDEV-15035 Wrong results when calling a stored procedureIgor Babaev2018-04-251-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | multiple times with different arguments. If the ON expression of an outer join is an OR formula with one of the disjunct being a constant formula then the expression cannot be null-rejected if the constant formula is true. Otherwise it can be null-rejected and if so the outer join can be converted into inner join. This optimization was added in the patch for mdev-4817. Yet the code had a defect: if the query was used in a stored procedure with parameters and the constant item contained some of them then the value of this constant item depended on the values of the parameters. With some parameters it may be true, for others not. The validity of conversion to inner join is checked only once and it happens only for the first call of procedure. So if the parameters in the first call allowed the conversion it was done and next calls used the transformed query though there could be calls whose parameters made the conversion invalid. Fixed by cheking whether the constant disjunct in the ON expression originally contained an SP parameter. If so the expression is not considered as null-rejected. For this check a new item's attribute was intruduced: Item::with_param. It is calculated for each item by fix fields() functions. Also moved the call of optimize_constant_subqueries() in JOIN::optimize after the call of simplify_joins(). The reason for this is that after the optimization introduced by the patch for mdev-4817 simplify_joins() can use the results of execution of non-expensive constant subqueries and this is not valid.
* | | | | Fixed mdev-15765 BETWEEN not working in certain casesIgor Babaev2018-04-101-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The implementations of the convert_to_basic_const_item() virtual function for the Item_cache classes should call cache_value() when value_cached == NULL.
* | | | | MDEV-15570 Assertion `Item_cache_temporal::field_type() != MYSQL_TYPE_TIME' ↵Sergei Golubchik2018-03-231-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | failed in Item_cache_temporal::val_datetime_packed remove an assert. TIME value can be used (and cached) in a datetime context
* | | | | Merge branch '10.1' into 10.2Vicențiu Ciorbaru2018-03-211-6/+8
|\ \ \ \ \ | |/ / / /
| * | | | MDEV-15321:different results when using value of ↵Varun Gupta2018-03-161-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | optimizer_use_condition_selectivity=4 and =1 To disallow equality propagation for DATETIME with non-zero YYYYMMDD part we were setting null_value to true. This caused issues when we were calculating selectivity for a condition as this returned IMPOSSIBLE WHERE. The issue is resolved by not setting null_value to true for DATETIME with non-zero YYYYMMDD.
* | | | | MDEV-11839 move value caching from get_datetime_value to fix_fields timeSergei Golubchik2018-03-141-18/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Refactor get_datetime_value() not to create Item_cache_temporal(), but do it always in ::fix_fields() or ::fix_length_and_dec(). Creating items at the execution time doesn't work very well with virtual columns and check constraints that are fixed and executed in different THDs.
View Lorry Controller Status