An error occurred fetching the project authors.
- 20 Aug, 2008 1 commit
-
-
Sergey Glukhov authored
Send_field.org_col_name has broken value on secondary execution. It happens when result field is created from the field which belongs to view due to forgotten assignment of some Send_field attributes. The fix: set Send_field.org_col_name,org_table_name with correct value during Send_field intialization.
-
- 30 Jul, 2008 1 commit
-
-
Georgi Kodinov authored
min() and max() functions are implemented in MySQL as macros. This means that max(a,b) is expanded to: ((a) > (b) ? (a) : (b)) Note how 'a' is quoted two times. Now imagine 'a' is a recursive function call that's several 10s of levels deep. And the recursive function does max() with a function arg as well to dive into recursion. This means that simple function call can take most of the clock time. Identified and fixed several such calls to max()/min() : including the IF() sql function implementation.
-
- 27 Jun, 2008 3 commits
-
-
Gleb Shchepa authored
Bug#35658 (An empty binary value leads to mysqld crash) Before this fix, the following token b'' caused the parser to crash when reading the binary value from the empty string. The crash was caused by: ptr+= max_length - 1; because max_length is unsigned and was 0, causing an overflow. With this fix, an empty binary literal b'' is parsed as a binary value 0, in Item_bin_string.
-
Gleb Shchepa authored
Bug#35658 (An empty binary value leads to mysqld crash) Before this fix, the following token b'' caused the parser to crash when reading the binary value from the empty string. The crash was caused by: ptr+= max_length - 1; because max_length is unsigned and was 0, causing an overflow. With this fix, an empty binary literal b'' is parsed as a binary value 0, in Item_bin_string.
-
Gleb Shchepa authored
Bug#35658 (An empty binary value leads to mysqld crash) Before this fix, the following token b'' caused the parser to crash when reading the binary value from the empty string. The crash was caused by: ptr+= max_length - 1; because max_length is unsigned and was 0, causing an overflow. With this fix, an empty binary literal b'' is parsed as a binary value 0, in Item_bin_string.
-
- 17 May, 2008 1 commit
-
-
kostja@bodhi.(none) authored
"Crash in subquery code when in PS and table DDL changed after PREPARE"
-
- 21 Apr, 2008 1 commit
-
-
sergefp@mysql.com authored
- Make convert_zerofill_number_to_string() take into account that the constant it is converting may evaluate to NULL.
-
- 08 Apr, 2008 1 commit
-
-
kostja@dipika.(none) authored
WL#4165 Prepared statements: validation WL#4166 Prepared statements: automatic re-prepare Fixes Bug#27430 Crash in subquery code when in PS and table DDL changed after PREPARE Bug#27690 Re-execution of prepared statement after table was replaced with a view crashes Bug#27420 A combination of PS and view operations cause error + assertion on shutdown The basic idea of the patch is to keep track of table metadata between prepared statement prepare and execute. If some table used in the statement has changed, the prepared statement is re-prepared before execution. See WL#4165 and WL#4166 contents and comments in the code for details of the implementation.
-
- 27 Mar, 2008 1 commit
-
-
evgen@moonbone.local authored
Mixing aggregate functions and non-grouping columns is not allowed in the ONLY_FULL_GROUP_BY mode. However in some cases the error wasn't thrown because of insufficient check. In order to check more thoroughly the new algorithm employs a list of outer fields used in a sum function and a SELECT_LEX::full_group_by_flag. Each non-outer field checked to find out whether it's aggregated or not and the current select is marked accordingly. All outer fields that are used under an aggregate function are added to the Item_sum::outer_fields list and later checked by the Item_sum::check_sum_func function.
-
- 14 Mar, 2008 1 commit
-
-
gshchepa/uchum@host.loc authored
Queries like: SELECT ROW(1, 2) IN (SELECT t1.a, 2) FROM t1 GROUP BY t1.a or SELECT ROW(1, 2) IN (SELECT t1.a, 2 FROM t2) FROM t1 GROUP BY t1.a lead to assertion failure in the Item_in_subselect::row_value_transformer method in debugging build, or to unexpected error message in release build: ERROR 1247 (42S22): Reference '<list ref>' not supported (forward reference in item list) Unexpected error message and assertion failure have been eliminated.
-
- 28 Feb, 2008 3 commits
-
-
davi@mysql.com/endora.local authored
must match the order which they were declared in the class definition.
-
davi@mysql.com/endora.local authored
The problem is that passing anything other than a integer to a limit clause in a prepared statement would fail. This limitation was introduced to avoid replication problems (e.g: replicating the statement with a string argument would cause a parse failure in the slave). The solution is to convert arguments to the limit clause to a integer value and use this converted value when persisting the query to the log.
-
NAME_CONST('whatever', -1) * MAX(whatever) bombed since -1 was not seen as constant, but as FUNCTION_UNARY_MINUS(constant) while we are at the same time pretending it was a basic const item. This confused the aggregate handlers in exciting ways. We now make NAME_CONST() behave more consistently.
-
- 22 Feb, 2008 1 commit
-
-
anozdrin/alik@quad. authored
between 5.0 and 5.1. The problem was that in the patch for Bug#11986 it was decided to store original query in UTF8 encoding for the INFORMATION_SCHEMA. This approach however turned out to be quite difficult to implement properly. The main problem is to preserve the same IS-output after dump/restore. So, the fix is to rollback to the previous functionality, but also to fix it to support multi-character-set-queries properly. The idea is to generate INFORMATION_SCHEMA-query from the item-tree after parsing view declaration. The IS-query should: - be completely in UTF8; - not contain character set introducers. For more information, see WL4052.
-
- 19 Feb, 2008 1 commit
-
-
svoj@mysql.com/june.mysql.com authored
breaks replication NAME_CONST() didn't replicate constant character set and collation correctly. With this fix NAME_CONST() inherits collation from the value argument.
-
- 18 Feb, 2008 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
-
- 15 Feb, 2008 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
when executed in version 5 Zero fill is a field attribute only. So we can't always propagate constants for zerofill fields : the values and expression results don't have that flag. Fixed by converting the const value to a string and using that in const propagation when the context allows it. Disable const propagation for fields with ZEROFILL flag in all the other cases.
-
- 12 Feb, 2008 2 commits
-
-
anozdrin/alik@quad. authored
but not collation. The problem here was that text literals in a view were always dumped with character set introducer. That lead to loosing collation information. The fix is to dump character set introducer only if it was in the original query. That is now possible because there is no problem any more of loss of character set of string literals in views -- after WL#4052 the view is dumped in the original character set.
-
kaa@mbp. authored
or trigger crashes server Under some circumstances a combination of VIEWs, subselects with outer references and PS/SP/triggers could lead to use of uninitialized memory and server crash as a result. Fixed by changing the code in Item_field::fix_fields() so that in cases when the field is a VIEW reference, we first check whether the field is also an outer reference, and mark it appropriately before returning.
-
- 08 Feb, 2008 2 commits
-
-
davi@mysql.com/endora.local authored
-
davi@mysql.com/endora.local authored
The unsignedness of large integer user variables was not being properly preserved when feeded to prepared statements. This was happening because the unsigned flags wasn't being updated when converting the user variable is converted to a parameter. The solution is to copy the unsigned flag when converting the user variable to a parameter and take the unsigned flag into account when converting the integer to a string.
-
- 27 Jan, 2008 1 commit
-
-
igor@olga.mysql.com authored
Two disjuncts containing equalities of the form key=const1 and key=const2 can be merged into one if const1 is equal to const2. To check it the common collation of the constants were used rather than the collation of the field key. For example when the default collation of the constants was cases insensitive while the collation of the field was case sensitive, then two or-ed equality predicates key='b' and key='B' incorrectly were merged into one f='b'. As a result ref access was used instead of range access and wrong result sets were returned in many cases. Fixed the problem by comparing constant in the or-ed predicate with collation of the key field.
-
- 11 Jan, 2008 1 commit
-
-
mhansson/martin@linux-st28.site authored
The name resolution for correlated subqueries and HAVING clauses failed to distinguish which of two was being performed when there was a reference to an outer aliased field. Fixed by adding the condition that HAVING clause name resulotion is being performed.
-
- 21 Dec, 2007 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
w/ Field_date instead of Field_newdate Field_date was still used in temp table creation. Fixed by using Field_newdate consistently throughout the server except when reading tables defined with older MySQL version. No test suite is possible because both Field_date and Field_newdate return the same values in all the metadata calls.
-
- 11 Dec, 2007 1 commit
-
-
mhansson/martin@linux-st28.site authored
There were two problems when inferring the correct field types resulting from UNION queries. - If the type is NULL for all corresponding fields in the UNION, the resulting type would be NULL, while the type is BINARY(0) if there is just a single SELECT NULL. - If one SELECT in the UNION uses a subselect, a temporary table is created to represent the subselect, and the result type defaults to a STRING type, hiding the fact that the type was unknown(just a NULL value). Fixed by remembering whenever a field was created from a NULL value and pass type NULL to the type coercion if that is the case, and creating a string field as result of UNION only if the type would otherwise be NULL.
-
- 08 Dec, 2007 1 commit
-
-
igor@olga.mysql.com authored
Both arguments of the function NAME_CONST must be constant expressions. This constraint is checked in the Item_name_const::fix_fields method. Yet if the argument of the function was not a constant expression no error message was reported. As a result the client hanged waiting for a response. Now the function Item_name_const::fix_fields reports an error message when any of the additional context conditions imposed on the function NAME_CONST is not satisfied.
-
- 27 Nov, 2007 1 commit
-
-
Problem: passing a non-constant name to the NAME_CONST function results in a crash. Fix: check the NAME_CONST name argument; return fake item type if we got non-constant argument(s).
-
- 20 Nov, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
only on some occasions Referencing an element from the SELECT list in a WHERE clause is not permitted. The namespace of the WHERE clause is the table columns only. This was not enforced correctly when resolving outer references in sub-queries. Fixed by not allowing references to aliases in a sub-query in WHERE.
-
- 13 Nov, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
The columns in HAVING can reference the GROUP BY and SELECT columns. There can be "table" prefixes when referencing these columns. And these "table" prefixes in HAVING use the table alias if available. This means that table aliases are subject to the same storage rules as table names and are dependent on lower_case_table_names in the same way as the table names are. Fixed by : 1. Treating table aliases as table names and make them lowercase when printing out the SQL statement for view persistence. 2. Using case insensitive comparison for table aliases when requested by lower_case_table_names
-
- 10 Nov, 2007 1 commit
-
-
gshchepa/uchum@gleb.loc authored
After adding an index the <VARBINARY> IN (SELECT <BINARY> ...) clause returned a wrong result: the VARBINARY value was illegally padded with zero bytes to the length of the BINARY column for the index search. (<VARBINARY>, ...) IN (SELECT <BINARY>, ... ) clauses are affected too.
-
- 23 Oct, 2007 1 commit
-
-
sergefp@mysql.com authored
- Let Item::save_in_field() call set_field_to_null_with_conversions() for decimal type, like this is done for the other item result types.
-
- 22 Oct, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
When doing indexed search the server constructs a key image for faster comparison to the stored keys. While doing that it must not perform (and stop if they fail) the additional date checks that can be turned on by the SQL mode because there already may be values in the table that don't comply with the error checks. Fixed by ignoring these SQL mode bits while making the key image.
-
- 21 Oct, 2007 1 commit
-
-
kaa@polly.(none) authored
Since, as of MySQL 5.0.15, CHAR() arguments larger than 255 are converted into multiple result bytes, a single CHAR() argument can now take up to 4 bytes. This patch fixes Item_func_char::fix_length_and_dec() to take this into account. This patch also fixes a regression introduced by the patch for bug21513. As now we do not always have the 'name' member of Item set for Item_hex_string and Item_bin_string, an own print() method has been added to Item_hex_string so that it could correctly be printed by Item_func::print_args().
-
- 15 Oct, 2007 1 commit
-
-
gluh@mysql.com/eagle.(none) authored
issue an error if string has illegal characters
-
- 11 Oct, 2007 2 commits
-
-
cmiller@zippy.cornsilk.net authored
-
gluh@mysql.com/eagle.(none) authored
Bug#30982 CHAR(..USING..) can return a not-well-formed string Bug#30986 Character set introducer followed by a HEX string can return bad result check_well_formed_result moved to Item from Item_str_func fixed Item_func_char::val_str for proper ucs symbols converting added check for well formed strings for correct conversion of constants with underscore charset
-
- 09 Oct, 2007 1 commit
-
-
Problem: creating a partitioned table during name resolution for the partition function we search for column names in all parts of the CREATE TABLE query. It is superfluous (and wrong) sometimes. Fix: launch name resolution for the partition function against the table we're creating.
-
- 05 Oct, 2007 1 commit
-
-
tnurnberg@sin.intern.azundris.com authored
convert(<invalid time>, datetime) in WHERE caused crash as function returned (void*)NULL, but did not flag SQL NULL. It does now.
-
- 04 Oct, 2007 1 commit
-
-
holyfoot/hf@mysql.com/hfmain.(none) authored
We use get_geometry_type() call to decide the exact type of a geometry field to be created (POINT, POLYGON etc) Though this function was only implemented for few items. In the bug's case we need to call this function for the Item_sum instance, where it was not implemented, what is the reason of the crash. Fixed by implementing virtual Item::get_geometry_type(), so it can be called for any Item.
-
- 28 Sep, 2007 1 commit
-
-
dkatz@damien-katzs-computer.local authored
Added #ifdef HAVE_SPATIAL around geometry related code.
-