An error occurred fetching the project authors.
- 11 Oct, 2007 1 commit
-
-
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
-
- 28 Sep, 2007 1 commit
-
-
mhansson/martin@linux-st28.site authored
The NAME_CONST function is required to work correctly with constants only. When executed with functions that return types other than those returned by Item::field_type (string, int, decimal, or real), the result gets cast to one of those types. This cannot happen for constants. Fixed by only allowing constants as arguments to NAME_CONST.
-
- 03 Aug, 2007 1 commit
-
-
bar@mysql.com/bar.myoffice.izhnet.ru authored
(Regression, caused by a patch for the bug 22646). Problem: when result type of date_format() was changed from binary string to character string, mixing date_format() with a ascii column in CONCAT() stopped to work. Fix: - adding "repertoire" flag into DTCollation class, to mark items which can return only pure ASCII strings. - allow character set conversion from pure ASCII to other character sets.
-
- 29 Jul, 2007 1 commit
-
-
gshchepa/uchum@gleb.loc authored
SP with local variables with non-ASCII names crashed the server. The server replaces SP local variable names with NAME_CONST calls when putting statements into the binary log. It used UTF8-encoded item names as variable names for the replacement inside NAME_CONST calls. However, statement string may be encoded by any known character set by the SET NAMES statement. The server used byte length of UTF8-encoded names to increment the position in the query string that led to array index overrun.
-
- 27 Jul, 2007 1 commit
-
-
holyfoot/hf@mysql.com/hfmain.(none) authored
Item_func_user doesn't calculate anything in it's val_str() method, just returns saved str_value. Though Item::save_in_field method can destroy str_value, relying on val_str() return. As a result we get the garbage stored in field. We cannot use Item::save_in_field implementation for Item_func_user, reimplement it in simpler way.
-
- 12 Jul, 2007 1 commit
-
-
kostja@bodhi.(none) authored
causes full table lock on innodb table. Also fixes Bug#28502 Triggers that update another innodb table will block on X lock unnecessarily (duplciate). Code review fixes. Both bugs' synopses are misleading: InnoDB table is not X locked. The statements, however, cannot proceed concurrently, but this happens due to lock conflicts for tables used in triggers, not for the InnoDB table. If a user had an InnoDB table, and two triggers, AFTER UPDATE and AFTER INSERT, competing for different resources (e.g. two distinct MyISAM tables), then these two triggers would not be able to execute concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would not be able to run concurrently. The problem had other side-effects (see respective bug reports). This behavior was a consequence of a shortcoming of the pre-locking algorithm, which would not distinguish between different DML operations (e.g. INSERT and DELETE) and pre-lock all the tables that are used by any trigger defined on the subject table. The idea of the fix is to extend the pre-locking algorithm to keep track, for each table, what DML operation it is used for and not load triggers that are known to never be fired.
-
- 06 Jul, 2007 1 commit
-
-
kostja@bodhi.(none) authored
The need arose when working on Bug 26141, where it became necessary to replace TABLE_LIST with its forward declaration in a few headers, and this involved a lot of s/TABLE_LIST/st_table_list/. Although other workarounds exist, this patch is in line with our general strategy of moving away from typedef-ed names. Sometime in future we might also rename TABLE_LIST to follow the coding style, but this is a huge change.
-
- 05 Jul, 2007 1 commit
-
-
igor@olga.mysql.com authored
This bug may manifest itself for select queries over a multi-table view that includes an ORDER BY clause in its definition. If the select list of the query contains references to the same view column with different aliases the names of the columns in the result output will be nevertheless the same, coinciding with one of the alias. The bug happened because the method Item_ref::get_tmp_table_item that was inherited by the class Item_direct_view_ref ignored the fact that the name of the view column reference must be inherited by the fields of the temporary table that was created in order to get the result rows sorted.
-
- 28 Jun, 2007 1 commit
-
-
anozdrin/alik@ibm. authored
SHOW CREATE TABLE or SELECT FROM I_S. Actually, the bug discovers two problems: - the original query is not preserved properly. This is the problem of BUG#16291; - the resultset of SHOW CREATE TABLE statement is binary. This patch fixes the second problem for the 5.0. Both problems will be fixed in 5.1.
-
- 20 Jun, 2007 1 commit
-
-
gshchepa/uchum@gleb.loc authored
For a join query with GROUP BY and/or ORDER BY and a view reference in the FROM list the metadata erroneously showed empty table aliases and database names for the view columns.
-
- 07 Jun, 2007 1 commit
-
-
evgen@moonbone.local authored
This bug was introduced by the fix for the bug#27300. In this fix a section of code was added to the Item::tmp_table_field_from_field_type method. This section intended to create Field_geom fields for the Item_geometry_func class and its descendants. In order to get the geometry type of the current item it casted "this" to the Item_geometry_func* type. But the Item::tmp_table_field_from_field_type method is also used for creation of fields for UNION and in this case this method is called for an object of the Item_type_holder class and the cast to the Item_geometry_func* type causes a server crash. Now the Item::tmp_table_field_from_field_type method correctly works when it's called for both the Item_type_holder and the Item_geometry_func classes. The new geometry_type variable is added to the Item_type_holder class. The new method called get_geometry_type is added to the Item_field and the Field classes. It returns geometry type from the field for the Item_field and the Field_geom classes and fails an assert for other Field descendants.
-
- 18 May, 2007 1 commit
- 16 May, 2007 1 commit
-
-
msvensson@pilot.blaudden authored
Made year 2000 handling more uniform Removed year 2000 handling out from calc_days() The above removes some bugs in date/datetimes with year between 0 and 200 Now we get a note when we insert a datetime value into a date column For default values to CREATE, don't give errors for warning level NOTE Fixed some compiler failures Added library ws2_32 for windows compilation (needed if we want to compile with IOCP support) Removed duplicate typedef TIME and replaced it with MYSQL_TIME Better (more complete) fix for: Bug#21103 "DATE column not compared as DATE" Fixed properly Bug#18997 "DATE_ADD and DATE_SUB perform year2K autoconversion magic on 4-digit year value" Fixed Bug#23093 "Implicit conversion of 9912101 to date does not match cast(9912101 as date)"
-
- 04 May, 2007 1 commit
-
-
evgen@moonbone.local authored
The LEAST/GREATEST functions compared DATE/DATETIME values as strings which in some cases could lead to a wrong result. A new member function called cmp_datetimes() is added to the Item_func_min_max class. It compares arguments in DATETIME context and returns index of the least/greatest argument. The Item_func_min_max::fix_length_and_dec() function now detects when arguments should be compared in DATETIME context and sets the newly added flag compare_as_dates. It indicates that the cmp_datetimes() function should be called to get a correct result. Item_func_min_max::val_xxx() methods are corrected to call the cmp_datetimes() function when needed. Objects of the Item_splocal class now stores and reports correct original field type.
-
- 26 Apr, 2007 1 commit
-
-
evgen@moonbone.local authored
DATE and DATETIME can be compared either as strings or as int. Both methods have their disadvantages. Strings can contain valid DATETIME value but have insignificant zeros omitted thus became non-comparable with other DATETIME strings. The comparison as int usually will require conversion from the string representation and the automatic conversion in most cases is carried out in a wrong way thus producing wrong comparison result. Another problem occurs when one tries to compare DATE field with a DATETIME constant. The constant is converted to DATE losing its precision i.e. losing time part. This fix addresses the problems described above by adding a special DATE/DATETIME comparator. The comparator correctly converts DATE/DATETIME string values to int when it's necessary, adds zero time part (00:00:00) to DATE values to compare them correctly to DATETIME values. Due to correct conversion malformed DATETIME string values are correctly compared to other DATE/DATETIME values. As of this patch a DATE value equals to DATETIME value with zero time part. For example '2001-01-01' equals to '2001-01-01 00:00:00'. The compare_datetime() function is added to the Arg_comparator class. It implements the correct comparator for DATE/DATETIME values. Two supplementary functions called get_date_from_str() and get_datetime_value() are added. The first one extracts DATE/DATETIME value from a string and the second one retrieves the correct DATE/DATETIME value from an item. The new Arg_comparator::can_compare_as_dates() function is added and used to check whether two given items can be compared by the compare_datetime() comparator. Two caching variables were added to the Arg_comparator class to speedup the DATE/DATETIME comparison. One more store() method was added to the Item_cache_int class to cache int values. The new is_datetime() function was added to the Item class. It indicates whether the item returns a DATE/DATETIME value.
-
- 15 Apr, 2007 1 commit
-
-
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.
-
- 20 Mar, 2007 1 commit
-
-
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.
-
- 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.
-
- 09 Mar, 2007 2 commits
-
-
evgen@moonbone.local authored
away. Additional fix for bug#22331. Now Item_field prints its value in the case of the const field.
-
anozdrin/alik@booka.opbmk authored
-
- 05 Mar, 2007 1 commit
-
-
igor@olga.mysql.com authored
The flag alias_name_used was not set on for the outer references in subqueries. It resulted in replacement of any outer reference resolved against an alias for a full field name when the frm representation of a view with a subquery was generated. If the subquery and the outer query referenced the same table in their from lists this replacement effectively changed the meaning of the view and led to wrong results for selects from this view. Modified several functions to ensure setting the right value of the alias_name_used flag for outer references resolved against aliases.
-
- 02 Mar, 2007 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
Several problems here : 1. The conversion to double of an hex string const item was not taking into account the unsigned flag. 2. IN was not behaving in the same was way as comparisons when performed over an INT/DATE/DATETIME/TIMESTAMP column and a constant. The ordinary comparisons in that case convert the constant to an INTEGER value and do int comparisons. Fixed the IN to do the same. 3. IN is not taking into account the unsigned flag when calculating <expr> IN (<int_const1>, <int_const2>, ...). Extended the implementation of IN to store and process the unsigned flag for its arguments.
-
- 26 Feb, 2007 1 commit
-
-
evgen@sunlight.local authored
Post fix for bug#23800.
-
- 25 Feb, 2007 1 commit
-
-
evgen@sunlight.local authored
Post fix for bug#23800. Copy the table name of an Item_outer_ref to the conventional memory.
-
- 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.
-
- 19 Feb, 2007 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
Several problems fixed: 1. There was a "catch-all" context initialization in setup_tables() that was causing the table that we insert into to be visible in the SELECT part of an INSERT .. SELECT .. statement with no tables in its FROM clause. This was making sure all the under-initialized contexts in various parts of the code are not left uninitialized. Fixed by removing the "catch-all" statement and initializing the context in the parser. 2. Incomplete name resolution context when resolving the right-hand values in the ON DUPLICATE KEY UPDATE ... part of an INSERT ... SELECT ... caused columns from NATURAL JOIN/JOIN USING table references in the FROM clause of the select to be unavailable. Fixed by establishing a proper name resolution context. 3. When setting up the special name resolution context for problem 2 there was no check for cases where an aggregate function without a GROUP BY effectively takes the column from the SELECT part of an INSERT ... SELECT unavailable for ON DUPLICATE KEY UPDATE. Fixed by checking for that condition when setting up the name resolution context.
-
- 16 Feb, 2007 1 commit
-
-
evgen@moonbone.local authored
UPDATE contains wrong data if the SELECT employs a temporary table. If the UPDATE values of the INSERT .. SELECT .. ON DUPLICATE KEY UPDATE statement contains fields from the SELECT part and the select employs a temporary table then those fields will contain wrong values because they aren't corrected to get data from the temporary table. The solution is to add these fields to the selects all_fields list, to store pointers to those fields in the selects ref_pointer_array and to access them via Item_ref objects. The substitution for Item_ref objects is done in the new function called Item_field::update_value_transformer(). It is called through the item->transform() mechanism at the end of the select_insert::prepare() function.
-
- 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.
-
- 23 Jan, 2007 1 commit
-
-
dlenev@mockturtle.local authored
on duplicate key". INSERT ... SELECT ... ON DUPLICATE KEY UPDATE which was used in stored routine or as prepared statement and which in its ON DUPLICATE KEY clause erroneously tried to assign value to a column mentioned only in its SELECT part was properly emitting error on the first execution but succeeded on the second and following executions. Code which is responsible for name resolution of fields mentioned in UPDATE clause (e.g. see select_insert::prepare()) modifies table list and Name_resolution_context used in this process. It uses Name_resolution_context_state::save_state/restore_state() to revert these modifications. Unfortunately those two methods failed to revert properly modifications to TABLE_LIST::next_name_resolution_table and this broke name resolution process for successive executions. This patch fixes Name_resolution_context_state::save_state/restore_state() in such way that it properly handles TABLE_LIST::next_name_resolution_table.
-
- 12 Jan, 2007 1 commit
-
-
igor@olga.mysql.com authored
in a select list. The objects of the Item_trigger_field class inherited the implementations of the methods copy_or_same, get_tmp_table_item and get_tmp_table_field from the class Item_field while they rather should have used the default implementations defined for the base class Item. It could cause catastrophic problems for triggers that used SELECTs with select list containing trigger fields such as NEW.<table column> under DISTINCT.
-
- 11 Jan, 2007 1 commit
-
-
evgen@moonbone.local authored
Currently in the ONLY_FULL_GROUP_BY mode no hidden fields are allowed in the select list. To ensure this each expression in the select list is checked to be a constant, an aggregate function or to occur in the GROUP BY list. The last two requirements are wrong and doesn't allow valid expressions like "MAX(b) - MIN(b)" or "a + 1" in a query with grouping by a. The correct check implemented by the patch will ensure that: any field reference in the [sub]expressions of the select list is under an aggregate function or is mentioned as member of the group list or is an outer reference or is part of the select list element that coincide with a grouping element. The Item_field objects now can contain the position of the select list expression which they belong to. The position is saved during the field's Item_field::fix_fields() call. The non_agg_fields list for non-aggregated fields is added to the SELECT_LEX class. The SELECT_LEX::cur_pos_in_select_list now contains the position in the select list of the expression being currently fixed.
-
- 31 Dec, 2006 1 commit
-
-
kent@mysql.com/kent-amd64.(none) authored
Corrected spelling in copyright text Makefile.am: Don't update the files from BitKeeper Many files: Removed "MySQL Finland AB & TCX DataKonsult AB" from copyright header Adjusted year(s) in copyright header Many files: Added GPL copyright text Removed files: Docs/Support/colspec-fix.pl Docs/Support/docbook-fixup.pl Docs/Support/docbook-prefix.pl Docs/Support/docbook-split Docs/Support/make-docbook Docs/Support/make-makefile Docs/Support/test-make-manual Docs/Support/test-make-manual-de Docs/Support/xwf
-
- 23 Dec, 2006 1 commit
-
-
kent@mysql.com/kent-amd64.(none) authored
Changed header to GPL version 2 only
-
- 22 Dec, 2006 1 commit
-
-
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.
-
- 09 Nov, 2006 1 commit
-
-
The problem was that any VIEW columns had always implicit derivation. Fix: derivation is now copied from the original expression given in VIEW definition. For example: - a VIEW column which comes from a string constant in CREATE VIEW definition have now coercible derivation. - a VIEW column having COLLATE clause in CREATE VIEW definition have now explicit derivation.
-
- 31 Oct, 2006 1 commit
-
-
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.
-
- 25 Oct, 2006 1 commit
-
-
holyfoot/hf@mysql.com/deer.(none) authored
-
- 09 Sep, 2006 1 commit
-
-
igor@rurik.mysql.com authored
-