An error occurred fetching the project authors.
- 04 May, 2007 2 commits
-
-
gkodinov/kgeorge@magare.gmz authored
fixed coverage of out-of-mem errors
-
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.
-
- 22 Mar, 2007 1 commit
-
-
jani@ua141d10.elisa.omakaista.fi authored
-
- 09 Mar, 2007 1 commit
-
-
anozdrin/alik@booka.opbmk authored
-
- 21 Feb, 2007 1 commit
-
-
monty@mysql.com/narttu.mysql.fi authored
This also fixes a bug in counting number of rows that are updated when we have many simultanous queries
-
- 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 2 commits
-
-
igor@olga.mysql.com authored
-
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.
-
- 24 Jan, 2007 1 commit
-
-
sergefp@mysql.com authored
identical pushed_cond_guards arrays. Allocate only one always.
-
- 12 Jan, 2007 2 commits
-
-
sergefp@mysql.com authored
- Make the code produce correct result: use an array of triggers to turn on/off equalities for each compared column. Also turn on/off optimizations based on those equalities. - Make EXPLAIN output show "Full scan on NULL key" for tables for which we switch between ref/unique_subquery/index_subquery and ALL access. - index_subquery engine now has HAVING clause when it is needed, and it is displayed in EXPLAIN EXTENDED - Fix incorrect presense of "Using index" for index/unique-based subqueries (BUG#22930) // bk trigger note: this commit refers to BUG#24127
-
sergefp@mysql.com authored
When transforming "oe IN (SELECT ie ...)" wrap the pushed-down predicates iff "oe can be null", not "ie can be null". The fix doesn't cover row-based subqueries, those will be fixed in #24127.
-
- 23 Dec, 2006 1 commit
-
-
kent@mysql.com/kent-amd64.(none) authored
Changed header to GPL version 2 only
-
- 14 Dec, 2006 1 commit
-
-
monty@mysql.com/narttu.mysql.fi authored
- Removed not used variables and functions - Added #ifdef around code that is not used - Renamed variables and functions to avoid conflicts - Removed some not used arguments Fixed some class/struct warnings in ndb Added define IS_LONGDATA() to simplify code in libmysql.c I did run gcov on the changes and added 'purecov' comments on almost all lines that was not just variable name changes
-
- 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 #)
-
- 17 Nov, 2006 1 commit
-
-
holyfoot/hf@mysql.com/deer.(none) authored
-
- 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.
-
- 31 Oct, 2006 3 commits
-
-
sergefp@mysql.com authored
- Better comments - Remove redundant and dead code.
-
sergefp@mysql.com authored
the fix.
-
sergefp@mysql.com authored
Evaluate "NULL IN (SELECT ...)" in a special way: Disable pushed-down conditions and their "consequences": = Do full table scans instead of unique_[index_subquery] lookups. = Change appropriate "ref_or_null" accesses to full table scans in subquery's joins. Also cache value of NULL IN (SELECT ...) if the SELECT is not correlated wrt any upper select.
-
- 20 Oct, 2006 2 commits
-
-
igor@rurik.mysql.com authored
-
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.
-
- 24 Aug, 2006 1 commit
-
-
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).
-
- 17 Aug, 2006 1 commit
-
-
jimw@rama.(none) authored
Fix when __attribute__() is stubbed out, add ATTRIBUTE_FORMAT() for specifying __attribute__((format(...))) safely, make more use of the format attribute, and fix some of the warnings that this turns up (plus a bonus unrelated one).
-
- 22 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
-
- 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.
-
- 09 Jun, 2006 1 commit
-
-
msvensson@neptunus.(none) authored
- Add unsigned flag to user_var_entry, used when 'type' is INT_RESULT - Propagate unsigned flag from the query executed by Item_single_row_subselect
-
- 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.
-
- 28 Apr, 2006 1 commit
-
-
gkodinov@lsmy3.wdf.sap.corp authored
In the code that converts IN predicates to EXISTS predicates it is changing the select list elements to constant 1. Example : SELECT ... FROM ... WHERE a IN (SELECT c FROM ...) is transformed to : SELECT ... FROM ... WHERE EXISTS (SELECT 1 FROM ... HAVING a = c) However there can be no FROM clause in the IN subquery and it may not be a simple select : SELECT ... FROM ... WHERE a IN (SELECT f(..) AS c UNION SELECT ...) This query is transformed to : SELECT ... FROM ... WHERE EXISTS (SELECT 1 FROM (SELECT f(..) AS c UNION SELECT ...) x HAVING a = c) In the above query c in the HAVING clause is made to be an Item_null_helper (a subclass of Item_ref) pointing to the real Item_field (which is not referenced anywhere else in the query anymore). This is done because Item_ref_null_helper collects information whether there are NULL values in the result. This is OK for directly executed statements, because the Item_field pointed by the Item_null_helper is already fixed when the transformation is done. But when executed as a prepared statement all the Item instances are "un-fixed" before the recompilation of the prepared statement. So when the Item_null_helper gets fixed it discovers that the Item_field it points to is not fixed and issues an error. The remedy is to keep the original select list references when there are no tables in the FROM clause. So the above becomes : SELECT ... FROM ... WHERE EXISTS (SELECT c FROM (SELECT f(..) AS c UNION SELECT ...) x HAVING a = c) In this way c is referenced directly in the select list as well as by reference in the HAVING clause. So it gets correctly fixed even with prepared statements. And since the Item_null_helper subclass of Item_ref_null_helper is not used anywhere else it's taken out.
-
- 20 Nov, 2005 1 commit
-
-
bell@sanja.is.com.ua authored
Bad examples of usage of a string with its length fixed. The incorrect length in the trigger file configuration descriptor fixed (BUG#14090). A hook for unknown keys added to the parser to support old .TRG files.
-
- 15 Oct, 2005 1 commit
-
-
igor@rurik.mysql.com authored
allowed set functions aggregated in outer subqueries, allowed nested set functions.
-
- 13 Oct, 2005 1 commit
-
-
konstantin@mysql.com authored
The bug was in JOIN::join_free which was wrongly determining that all joins have been already executed and therefore all used tables can be closed.
-
- 21 Sep, 2005 1 commit
-
-
konstantin@mysql.com authored
cursor is interpreted latin1 character and Bug#9819 "Cursors: Mysql Server Crash while fetching from table with 5 million records." A fix for a possible memory leak when fetching into an SP cursor in a long loop. The patch uses a common implementation of cursors in the binary protocol and in stored procedures and implements materialized cursors. For implementation details, see comments in sql_cursor.cc
-
- 02 Sep, 2005 1 commit
-
-
konstantin@mysql.com authored
- current_arena to stmt_arena: the thread may have more than one 'current' arenas: one for runtime data, and one for the parsed tree of a statement. Only one of them is active at any moment. - set_item_arena -> set_query_arena, because Item_arena was renamed to Query_arena a while ago - set_n_backup_item_arena -> set_n_backup_active_arena; the active arena is the arena thd->mem_root and thd->free_list are currently pointing at. - restore_backup_item_arena -> restore_active_arena (with the same rationale) - change_arena_if_needed -> activate_stmt_arena_if_needed; this method sets thd->stmt_arena active if it's not done yet.
-
- 13 Aug, 2005 2 commits
-
-
sanja@hasky.mysql.fi authored
postmerge fix subselect.result: new 5.0 result (postmerge)
-
bell@50.0.168.192.in-addr.arpa authored
-
- 09 Aug, 2005 1 commit
-
-
dlenev@mysql.com authored
cause crash on update". Let us update "thd" pointer in LEX, all its units and in LEX::result before executing statement in trigger body, since triggers are associated with TABLE object and because of this can be used in different threads.
-