An error occurred fetching the project authors.
- 29 Jun, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
query / no aggregate of subquery The optimizer counts the aggregate functions that appear as top level expressions (in all_fields) in the current subquery. Later it makes a list of these that it uses to actually execute the aggregates in end_send_group(). That count is used in several places as a flag whether there are aggregates functions. While collecting the above info it must not consider aggregates that are not aggregated in the current context. It must treat them as normal expressions instead. Not doing that leads to incorrect data about the query, e.g. running a query that actually has no aggregate functions as if it has some (and hence is expected to return only one row). Fixed by ignoring the aggregates that are not aggregated in the current context. One other smaller omission discovered and fixed in the process : the place of aggregation was not calculated for user defined functions. Fixed by calling Item_sum::init_sum_func_check() and Item_sum::check_sum_func() as it's done for the rest of the aggregate functions.
-
- 22 Jun, 2007 1 commit
-
-
bar@mysql.com/bar.myoffice.izhnet.ru authored
Problem: separator was not converted to the result character set, so the result was a mixture of two different character sets, which was especially bad for UCS2. Fix: convert separator to the result character set.
-
- 21 May, 2007 1 commit
-
-
mhansson@dl145s.mysql.com authored
-
- 11 May, 2007 1 commit
-
-
mhansson/martin@linux-st28.site authored
When using GROUP_CONCAT with ORDER BY, a tree is used for the sorting, as opposed to normal nested loops join used when there is no ORDER BY. The tree traversal that generates the result counts the lines that have been cut down. (as they get cut down to the field's max_size) But the check of that count was before the tree traversal, so no warning was generated if the output is truncated. Fixed by moving the check to after the tree traversal.
-
- 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.
-
- 29 Mar, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
When creating a temporary table the concise column type of a string expression is decided based on its length: - if its length is under 512 it is stored as either varchar or char. - otherwise it is stored as a BLOB. There is a flag (convert_blob_length) to create_tmp_field that, when >0 allows to force creation of a varchar if the max blob length is under convert_blob_length. However it must be verified that convert_blob_length (settable through a SQL option in some cases) is under the maximum that can be stored in a varchar column. While performing that check for expressions in create_tmp_field_from_item the max length of the blob was used instead. This causes blob columns to be created in the heap temp table used by GROUP_CONCAT (where blobs must not be created in the temp table because of the constant convert_blob_length that is passed to create_tmp_field() ). And since these blob columns are not expected in that place we get wrong results. Fixed by checking that the value of the flag variable is in the limits that fit into VARCHAR instead of the max length of the blob column.
-
- 27 Mar, 2007 2 commits
-
-
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.
-
gkodinov/kgeorge@magare.gmz authored
When creating a temporary table the concise column type of a string expression is decided based on its length: - if its length is under 512 it is stored as either varchar or char. - otherwise it is stored as a BLOB. There is a flag (convert_blob_length) to create_tmp_field that, when >0 allows to force creation of a varchar if the max blob length is under convert_blob_length. However it must be verified that convert_blob_length (settable through a SQL option in some cases) is under the maximum that can be stored in a varchar column. While performing that check for expressions in create_tmp_field_from_item the max length of the blob was used instead. This causes blob columns to be created in the heap temp table used by GROUP_CONCAT (where blobs must not be created in the temp table because of the constant convert_blob_length that is passed to create_tmp_field() ). And since these blob columns are not expected in that place we get wrong results. Fixed by checking that the value of the flag variable is in the limits that fit into VARCHAR instead of the max length of the blob column.
-
- 26 Mar, 2007 1 commit
-
-
igor@olga.mysql.com authored
from func_group.test after the patch for bug #27229 had been applied. The memory corruption happened because in some rare cases the function count_field_types underestimated the number of elements in in the array param->items_to_copy.
-
- 22 Mar, 2007 2 commits
-
-
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.
-
mhansson/martin@linux-st28.site authored
The problem in this bug is when we create temporary tables. When temporary tables are created for unions, there is some inferrence being carried out regarding the type of the column. Whenever this column type is inferred to be REAL (i.e. FLOAT or DOUBLE), MySQL will always try to maintain exact precision, and if that is not possible (there are hardware limits, since FLOAT and DOUBLE are stored as approximate values) will switch to using approximate values. The problem here is that at this point the information about number of significant digits is not available. Furthermore, the number of significant digits should be increased for the AVG function, however, this was not properly handled. There are 4 parts to the problem: #1: DOUBLE and FLOAT fields don't display their proper display lengths in max_display_length(). This is hard-coded as 53 for DOUBLE and 24 for FLOAT. Now changed to instead return the field_length. #2: Type holders for temporary tables do not preserve the max_length of the Item's from which they are created, and is instead reverted to the 53 and 24 from above. This causes *all* fields to get non-fixed significant digits. #3: AVG function does not update max_length (display length) when updating number of decimals. #4: The function that switches to non-fixed number of significant digits should use DBL_DIG + 2 or FLT_DIG + 2 as cut-off values (Since fixed precision does not use the 'e' notation) Of these points, #1 is the controversial one, but this change is preferred and has been cleared with Monty. The function causes quite a few unit tests to blow up and they had to b changed, but each one is annotated and motivated. We frequently see the magical 53 and 24 give way to more relevant numbers.
-
- 20 Mar, 2007 2 commits
-
-
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.
-
gkodinov/kgeorge@macbook.local authored
To correctly decide which predicates can be evaluated with a given table the optimizer must know the exact set of tables that a predicate depends on. If that mask is too wide (refer to non-existing tables) the optimizer can erroneously skip a predicate. One such case of wrong table usage mask were the aggregate functions. The have a all-1 mask (meaning depend on all tables, including non-existent ones). Fixed by making a real used_tables mask for the aggregates. The mask is constructed in the following way : 1. OR the table dependency masks of all the arguments of the aggregate. 2. If all the arguments of the function are from the local name resolution context and it is evaluated in the same name resolution context where it is referenced all the tables from that name resolution context are OR-ed to the dependency mask. This is to denote that an aggregate function depends on the number of rows it processes. 3. Handle correctly the case of an aggregate function optimization (such that the aggregate function can be pre-calculated and made a constant). Made sure that an aggregate function is never a constant (unless subject of a specific optimization and pre-calculation). One other flaw was revealed and fixed in the process : references were not calling the recalculation method for used_tables of their targets.
-
- 31 Jan, 2007 1 commit
-
-
- 23 Dec, 2006 1 commit
-
-
kent@mysql.com/kent-amd64.(none) authored
Changed header to GPL version 2 only
-
- 22 Dec, 2006 2 commits
-
-
cmiller@zippy.cornsilk.net authored
When only one row was present, the subtraction of nearly the same number resulted in catastropic cancellation, introducing an error in the VARIANCE calculation near 1e-15. That was sqrt()ed to get STDDEV, the error was escallated to near 1e-8. The simple fix of testing for a row count of 1 and forcing that to yield 0.0 is insufficient, as two rows of the same value should also have a variance of 0.0, yet the error would be about the same. So, this patch changes the formula that computes the VARIANCE to be one that is not subject to catastrophic cancellation. In addition, it now uses only (faster-than-decimal) floating point numbers to calculate, and renders that to other types on demand.
-
We use val_int() calls (followed by null_value check) to determine nullness in some Item_sum_count' and Item_sum_count_distinct' methods, as a side effect we get extra warnings raised in the val_int(). Fix: use is_null() instead.
-
- 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
-
- 28 Nov, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
When implicitly converting string fields to numbers the string-to-number conversion error was not sent to the client. Added code to send the conversion error as warning. We also need to prevent generation of warnings from the places where val_xxx() methods are called for the sole purpose of updating the Item::null_value flag. To achieve that a special function is added (and called) : update_null_value(). This function will set the no_errors flag and will call val_xxx(). The warning generation in Field_string::val_xxx() will use the flag when generating the conversion warnings.
-
- 27 Nov, 2006 1 commit
-
-
monty@mysql.com/nosik.monty.fi authored
Initialize key_part->type on open. This caused key_copy() to fail for bit_fields. (key_copy is used in HANDLER and opt_range)
-
- 22 Nov, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
expression cols. The problem was that MYSQL_FIELD::org_name was set for MIN() and MAX() functions (COUNT() is also mentioned in the bug report but was already fixed). After this patch for expressions MYSQL_FIELD::name is set to either expression itself or its alias, and other data origin fields of MYSQL_FILED (db, org_table, table, org_name) are empty strings.
-
- 08 Nov, 2006 1 commit
-
-
- 07 Nov, 2006 1 commit
-
-
Problem: GROUP_CONCAT on a multi-byte column can truncate in the middle of a multibyte character when applying group_concat_max_len limit. It produces an invalid multi-byte character in the result string. The second, easier version - reusing old "warning_for_row" flag, instead of introducing of "result_is_full" - which was added in the previous commit.
-
- 31 Oct, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
Item::val_xxx() may be called by the server several times at execute time for a single query. Calls to val_xxx() may be very expensive and sometimes (count(distinct), sum(distinct), avg(distinct)) not possible. To avoid that problem the results of calculation for these aggregate functions are cached so that val_xxx() methods just return the calculated value for the second and subsequent calls.
-
- 18 Oct, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
(COUNT(*) = 1) not working in SELECT inside prepared statement. Note: the warning was introduced in 5.0 and 5.1, 4.1 is OK with the original fix. The problem was that in 5.0 and 5.1 clear() for group functions may access hybrid_type member, and this member is initialized in fix_fields(). So we should not call clear() from item cleanup() methods, as cleanup() may be called for unfixed items.
-
- 10 Oct, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
statement. The problem was that during statement re-execution if the result was empty the old result could be returned for group functions. The solution is to implement proper cleanup() method in group functions.
-
- 28 Sep, 2006 1 commit
-
-
stewart@willster.(none) authored
post-review fixes as indicated by Serg. manual testing of error cases done in 5.0 due to support for DBUG_EXECUTE_IF to insert errors. Unable to write test case for mysql-test until 5.1 due to support for setting debug options at runtime.
-
- 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.
-
- 01 Sep, 2006 1 commit
-
-
sergefp@mysql.com authored
make st_select_lex::setup_ref_array() take into account that Item_sum-descendant objects located within descendant SELECTs may be added into ref_pointer_array.
-
- 25 Jul, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
when calculating GROUP_CONCAT all blob fields are transformed to varchar when making the temp table. However a varchar has at max 2 bytes for length. This fix makes the conversion only for blobs whose max length is below that limit. Otherwise blob field is created by make_string_field() call.
-
- 30 Jun, 2006 1 commit
-
-
knielsen@mysql.com authored
In some functions dealing with strings and character sets, the wrong pointers were saved for restoration in THD::rollback_item_tree_changes(). This could potentially cause random corruption or crashes. Fixed by passing the original Item ** locations, not local stack copies. Also remove unnecessary use of default arguments.
-
- 22 Jun, 2006 1 commit
-
-
igor@rurik.mysql.com authored
Server crashed in some cases when a query required a MIN/MAX agrregation for a 'ucs2' field. In these cases the aggregation caused calls of the function update_tmptable_sum_func that indirectly invoked the method Item_sum_hybrid::min_max_update_str_field() containing a call to strip_sp for a ucs2 character set. The latter led directly to the crash as it used my_isspace undefined for the ucs2 character set. Actually the call of strip_sp is not needed at all in this situation and has been removed by the fix.
-
- 20 Apr, 2006 1 commit
-
-
igor@rurik.mysql.com authored
-
- 07 Apr, 2006 1 commit
-
-
gluh@eagle.intranet.mysql.r18.ru authored
skip charset aggregation for order columns
-
- 30 Mar, 2006 1 commit
-
-
evgen@sunlight.local authored
After merge fix for bug#15560 item_sum.h: After merge fix for bug#15560
-
- 29 Mar, 2006 1 commit
-
-
evgen@moonbone.local authored
The GROUP_CONCAT uses its own temporary table. When ROLLUP is present it creates the second copy of Item_func_group_concat. This copy receives the same list of arguments that original group_concat does. When the copy is set up the result_fields of functions from the argument list are reset to the temporary table of this copy. As a result of this action data from functions flow directly to the ROLLUP copy and the original group_concat functions shows wrong result. Since queries with COUNT(DISTINCT ...) use temporary tables to store the results the COUNT function they are also affected by this bug. The idea of the fix is to copy content of the result_field for the function under GROUP_CONCAT/COUNT from the first temporary table to the second one, rather than setting result_field to point to the second temporary table. To achieve this goal force_copy_fields flag is added to Item_func_group_concat and Item_sum_count_distinct classes. This flag is initialized to 0 and set to 1 into the make_unique() member function of both classes. To the TMP_TABLE_PARAM structure is modified to include the similar flag as well. The create_tmp_table() function passes that flag to create_tmp_field(). When the flag is set the create_tmp_field() function will set result_field as a source field and will not reset that result field to newly created field for Item_func_result_field and its descendants. Due to this there will be created copy func to copy data from old result_field to newly created field.
-
- 05 Mar, 2006 1 commit
-
-
holyfoot@deer.(none) authored
-
- 30 Nov, 2005 1 commit
-
-
ramil@mysql.com authored
- use rint() in some other val_int() methods as well.
-
- 22 Nov, 2005 1 commit
-
-
ramil@mysql.com authored
-
- 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.
-