An error occurred fetching the project authors.
- 17 May, 2007 1 commit
-
-
igor@olga.mysql.com authored
subqueries in WHERE conditions. This bug was introduced by the patch for bug 27321.
-
- 04 May, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
Non-correlated scalar subqueries may get executed in EXPLAIN at the optimization phase if they are part of a right hand sargable expression. If the scalar subquery uses a temp table to materialize its results it will replace the subquery structure from the parser with a simple select from the materialization table. As a result the EXPLAIN will crash as the temporary materialization table is not to be shown in EXPLAIN at all. Fixed by preserving the original query structure right after calling optimize() for scalar subqueries with temp tables executed during EXPLAIN.
-
- 26 Apr, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
Validity checks for nested set functions were not taking into account that the enclosed set function may be on a nest level that is lower than the nest level of the enclosing set function. Fixed by : - propagating max_sum_func_level up the enclosing set functions chain. - updating the max_sum_func_level of the enclosing set function when the enclosed set function is aggregated above or on the same nest level of as the level of the enclosing set function. - updating the max_arg_level of the enclosing set function on a reference that refers to an item above or on the same nest level as the level of the enclosing set function. - Treating both Item_field and Item_ref as possibly referencing items from outer nest levels.
-
- 15 Apr, 2007 2 commits
-
-
evgen@moonbone.local authored
After merge fix.
-
evgen@moonbone.local authored
The Item_outer_ref class based on the Item_direct_ref class was always used to represent an outer field. But if the outer select is a grouping one and the outer field isn't under an aggregate function which is aggregated in that outer select an Item_ref object should be used to represent such a field. If the outer select in which the outer field is resolved isn't grouping then the Item_field class should be used to represent such a field. This logic also should be used for an outer field resolved through its alias name. Now the Item_field::fix_outer_field() uses Item_outer_field objects to represent aliased and non-aliased outer fields for grouping outer selects only. Now the fix_inner_refs() function chooses which class to use to access outer field - the Item_ref or the Item_direct_ref. An object of the chosen class substitutes the original field in the Item_outer_ref object. The direct_ref and the found_in_select_list fields were added to the Item_outer_ref class.
-
- 27 Mar, 2007 1 commit
-
-
igor@olga.mysql.com authored
If a set function with a outer reference s(outer_ref) cannot be aggregated the outer query against which the reference has been resolved then MySQL interpretes s(outer_ref) in the same way as it would interpret s(const). Hovever the standard requires throwing an error in this situation. Added some code to support this requirement in ansi mode. Corrected another minor bug in Item_sum::check_sum_func.
-
- 22 Mar, 2007 1 commit
-
-
igor@olga.mysql.com authored
context was used as an argument of GROUP_CONCAT. Ensured correct setting of the depended_from field in references generated for set functions aggregated in outer selects. A wrong value of this field resulted in wrong maps returned by used_tables() for these references. Made sure that a temporary table field is added for any set function aggregated in outer context when creation of a temporary table is needed to execute the inner subquery.
-
- 20 Mar, 2007 1 commit
-
-
igor@olga.mysql.com authored
aggregated in outer context returned wrong results. This happened only if the subquery did not contain any references to outer fields. As there were no references to outer fields the subquery erroneously was taken for non-correlated one. Now any set function aggregated in outer context makes the subquery correlated.
-
- 12 Mar, 2007 1 commit
-
-
igor@olga.mysql.com authored
when the column is to be read from a derived table column which was specified as a concatenation of string literals. The bug happened because the Item_string::append did not adjust the value of Item_string::max_length. As a result of it the temporary table column defined to store the concatenation of literals was not wide enough to hold the whole value.
-
- 01 Mar, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
-
- 21 Feb, 2007 1 commit
-
-
evgen@moonbone.local authored
created for sorting. Any outer reference in a subquery was represented by an Item_field object. If the outer select employs a temporary table all such fields should be replaced with fields from that temporary table in order to point to the actual data. This replacement wasn't done and that resulted in a wrong subquery evaluation and a wrong result of the whole query. Now any outer field is represented by two objects - Item_field placed in the outer select and Item_outer_ref in the subquery. Item_field object is processed as a normal field and the reference to it is saved in the ref_pointer_array. Thus the Item_outer_ref is always references the correct field. The original field is substituted for a reference in the Item_field::fix_outer_field() function. New function called fix_inner_refs() is added to fix fields referenced from inner selects and to fix references (Item_ref objects) to these fields. The new Item_outer_ref class is a descendant of the Item_direct_ref class. It additionally stores a reference to the original field and designed to behave more like a field.
-
- 16 Feb, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
-
- 30 Jan, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
Before this fix, a IN predicate of the form: "IN (( subselect ))", with two parenthesis, would be evaluated as a single row subselect: if the subselect returns more that 1 row, the statement would fail. The SQL:2003 standard defines a special exception in the specification, and mandates that this particular form of IN predicate shall be equivalent to "IN ( subselect )", which involves a table subquery and works with more than 1 row. This fix implements "IN (( subselect ))", "IN ((( subselect )))" etc as per the SQL:2003 requirement. All the details related to the implementation of this change have been commented in the code, and the relevant sections of the SQL:2003 spec are given for reference, so they are not repeated here. Having access to the spec is a requirement to review in depth this patch.
-
- 26 Jan, 2007 1 commit
-
-
igor@olga.mysql.com authored
The bug report has demonstrated the following two problems. 1. If an ORDER/GROUP BY list includes a constant expression being optimized away and, at the same time, containing single-row subselects that return more that one row, no error is reported. Strictly speaking the standard allows to ignore error in this case. Yet, now a corresponding fatal error is reported in this case. 2. If a query requires sorting by expressions containing single-row subselects that, however, return more than one row, then the execution of the query may cause a server crash. To fix this some code has been added that blocks execution of a subselect item in case of a fatal error in the method Item_subselect::exec.
-
- 19 Jan, 2007 1 commit
-
-
igor@olga.mysql.com authored
UNION over correlated and uncorrelated SELECTS. In such subqueries each uncorrelated SELECT should be considered as uncacheable. Otherwise join_free is called for it and in many cases it causes some problems.
-
- 12 Dec, 2006 1 commit
-
-
igor@olga.mysql.com authored
and no WHERE condition were applied for any subquery without tables.
-
- 20 Nov, 2006 1 commit
-
-
monty@mysql.com/nosik.monty.fi authored
(Mostly in DBUG_PRINT() and unused arguments) Fixed bug in query cache when used with traceing (--with-debug) Fixed memory leak in mysqldump Removed warnings from mysqltest scripts (replaced -- with #)
-
- 07 Nov, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
- When returning metadata for scalar subqueries the actual type of the column was calculated based on the value type, which limits the actual type of a scalar subselect to the set of (currently) 3 basic types : integer, double precision or string. This is the reason that columns of types other then the basic ones (e.g. date/time) are reported as being of the corresponding basic type. Fixed by storing/returning information for the column type in addition to the result type.
-
- 01 Nov, 2006 1 commit
-
-
igor@rurik.mysql.com authored
This is a performance issue for queries with subqueries evaluation of which requires filesort. Allocation of memory for the sort buffer at each evaluation of a subquery may take a significant amount of time if the buffer is rather big. With the fix we allocate the buffer at the first evaluation of the subquery and reuse it at each subsequent evaluation.
-
- 20 Oct, 2006 1 commit
-
-
igor@rurik.mysql.com authored
If elements a not top-level IN subquery were accessed by an index and the subquery result set included a NULL value then the quantified predicate that contained the subquery was evaluated to NULL when it should return a non-null value.
-
- 17 Oct, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
list using a function When executing dependent subqueries they are re-inited and re-exec() for each row of the outer context. The cause for the bug is that during subquery reinitialization/re-execution, the optimizer reallocates JOIN::join_tab, JOIN::table in make_simple_join() and the local variable in 'sortorder' in create_sort_index(), which is allocated by make_unireg_sortorder(). Care must be taken not to allocate anything into the thread's memory pool while re-initializing query plan structures between subquery re-executions. All such items mush be cached and reused because the thread's memory pool is freed at the end of the whole query. Note that they must be cached and reused even for queries that are not otherwise cacheable because otherwise it will grow the thread's memory pool every time a cacheable query is re-executed. We provide additional members to the JOIN structure to store references to the items that need to be cached.
-
- 03 Oct, 2006 1 commit
-
-
msvensson@shellback.(none) authored
- ie. backport from 5.1 - also update testcase error dected by new version
-
- 25 Sep, 2006 1 commit
-
-
igor@rurik.mysql.com authored
an ALL/ANY quantified subquery in HAVING. The Item::split_sum_func2 method should not create Item_ref for objects of any class derived from Item_subselect.
-
- 08 Sep, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
wrong results Mark the containing Item(s) (Item_subselect descendant usually) of a subselect as containing aggregate functions if it has references to aggregates functions that are calculated outside its context. This tels end_send_group() not to make an Item_subselect descendant in select list a copy and causes the correct value being returned.
-
- 31 Aug, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
Made the parser to support parenthesis around UNION branches. This is done by amending the rules of the parser so it generates the correct structure. Currently it supports arbitrary subquery/join/parenthesis operations in the EXISTS clause. In the IN/scalar subquery case it will allow adding nested parenthesis only if there is an UNION clause after the parenthesis. Otherwise it will just treat the multiple nested parenthesis as a scalar expression. It adds extra lex level for ((SELECT ...) UNION ...) to accommodate for the UNION clause.
-
- 24 Aug, 2006 2 commits
-
-
sergefp@mysql.com authored
-
sergefp@mysql.com authored
Must not use Item_direct_ref in HAVING because it points to the new value (witch is not yet calculated for the first row).
-
- 03 Aug, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
Reseting subqueries with "quick" access methods was incomplete. Partially backported the correct reseting of QUICK_SELECTs from 5.x.
-
- 21 Jul, 2006 1 commit
-
-
sergefp@mysql.com authored
-
- 20 Jul, 2006 1 commit
-
-
sergefp@mysql.com authored
Add implementations of Item_func_{nop,not}_all::neg_transformer
-
- 15 Jul, 2006 2 commits
-
-
igor@rurik.mysql.com authored
The bug caused a crash of the server if a subquery with ORDER BY DESC used the range access method. The bug happened because the method QUICK_SELECT_DESC::reset was not reworked after MRR interface had been introduced.
-
igor@olga.mysql.com authored
The bug was due to a loss happened during a refactoring made on May 30 2005 that modified the function JOIN::reinit. As a result of it for any subquery the value of offset_limit_cnt was not restored for the following executions. Yet the first execution of the subquery made it equal to 0. The fix restores this value in the function JOIN::reinit.
-
- 11 Jul, 2006 1 commit
-
-
evgen@moonbone.local authored
may return a wrong result. An Item_sum_hybrid object has the was_values flag which indicates whether any values were added to the sum function. By default it is set to true and reset to false on any no_rows_in_result() call. This method is called only in return_zero_rows() function. An ALL/ANY subquery can be optimized by MIN/MAX optimization. The was_values flag is used to indicate whether the subquery has returned at least one row. This bug occurs because return_zero_rows() is called only when we know that the select will return zero rows before starting any scans but often such information is not known. In the reported case the return_zero_rows() function is not called and the was_values flag is not reset to false and yet the subquery return no rows Item_func_not_all and Item_func_nop_all functions return a wrong comparison result. The end_send_group() function now calls no_rows_in_result() for each item in the fields_list if there is no rows were found for the (sub)query.
-
- 10 Jul, 2006 1 commit
-
-
evgen@moonbone.local authored
The ALL/ANY subqueries are the subject of MIN/MAX optimization. The matter of this optimization is to embed MIN() or MAX() function into the subquery in order to get only one row by which we can tell whether the expression with ALL/ANY subquery is true or false. But when it is applied to a subquery like 'select a_constant' the reported bug occurs. As no tables are specified in the subquery the do_select() function isn't called for the optimized subquery and thus no values have been added to a MIN()/MAX() function and it returns NULL instead of a_constant. This leads to a wrong query result. For the subquery like 'select a_constant' there is no reason to apply MIN/MAX optimization because the subquery anyway will return at most one row. Thus the Item_maxmin_subselect class is more appropriate for handling such subqueries. The Item_in_subselect::single_value_transformer() function now checks whether tables are specified for the subquery. If no then this subselect is handled like a UNION using an Item_maxmin_subselect object.
-
- 25 May, 2006 1 commit
-
-
gkodinov@mysql.com authored
The unsigned flag in Item was not propagated through the single value subqueries. This caused the result to be treated as signed.
-
- 17 May, 2006 1 commit
-
-
evgen@moonbone.local authored
The convert_constant_item() function converts constant items to ints on prepare phase to optimize execution speed. In this case it tries to evaluate subselect which contains a derived table and is contained in a derived table. All derived tables are filled only after all derived tables are prepared. So evaluation of subselect with derived table at the prepare phase will return a wrong result. A new flag with_subselect is added to the Item class. It indicates that expression which this item represents is a subselect or contains a subselect. It is set to 0 by default. It is set to 1 in the Item_subselect constructor for subselects. For Item_func and Item_cond derived classes it is set after fixing any argument in Item_func::fix_fields() and Item_cond::fix_fields accordingly. The convert_constant_item() function now doesn't convert a constant item if the with_subselect flag set in it.
-
- 11 May, 2006 1 commit
-
-
gkodinov@mysql.com authored
When a view statement is compiled on CREATE VIEW time, most of the optimizations should not be done. Finding the right optimization for a subquery is one of them. Unfortunately the optimizer is resolving the column references of the left expression of IN subqueries in the process of deciding witch optimization to use (if needed). So there should be a special case in Item_in_subselect::fix_fields() : check the validity of the left expression of IN subqueries in CREATE VIEW mode and then proceed as normal.
-
- 23 Mar, 2006 1 commit
-
-
ramil@mysql.com authored
-
- 13 Mar, 2006 1 commit
-
-
evgen@sunlight.local authored
When there is conjunction of conds, the substitute_for_best_equal_field() will call the eliminate_item_equal() function in loop to build final expression. But if eliminate_item_equal() finds that some cond will always evaluate to 0, then that cond will be substituted by Item_int with value == 0. In this case on the next iteration eliminate_item_equal() will get that Item_int and treat it as Item_cond. This is leads to memory corruption and server crash on cleanup phase. To the eliminate_item_equal() function was added DBUG_ASSERT for checking that all items treaten as Item_cond are really Item_cond. The substitute_for_best_equal_field() now checks that if eliminate_item_equal() returns Item_int and it's value is 0 then this value is returned as the result of whole conjunction.
-
- 24 Feb, 2006 1 commit
-
-
monty@mysql.com authored
(Needed for "list of pushes" web page and autopush)
-