An error occurred fetching the project authors.
- 05 Feb, 2009 1 commit
-
-
Gleb Shchepa authored
Documented behaviour was broken by the patch for bug 33699 that actually is not a bug. This fix reverts patch for bug 33699 and reverts the UPDATE of NOT NULL field with NULL query to old behavior.
-
- 15 Aug, 2008 1 commit
-
-
Chad MILLER authored
Length value is the length of the field, Max_length is the length of the field value. So Max_length can not be more than Length. The fix: fixed calculation of the Item_empty_string item length (Patch applied and queued on demand of Trudy/Davi.)
-
- 11 Jan, 2008 1 commit
-
-
gshchepa/uchum@host.loc authored
columns (default datatype value is assigned). The mysql_update function has been modified to generate an error when trying to set a NOT NULL field to NULL rather than a warning in the set_field_to_null_with_conversions function.
-
- 06 Dec, 2007 1 commit
-
-
additional fixes for BDB and correct assignment of both signed and unsigned 64-bit data to unsigned system variables
-
- 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
-
-
evgen@moonbone.local authored
command and reported to a client. The fact that a timestamp field will be set to NO on UPDATE wasn't shown by the SHOW COMMAND and reported to a client through connectors. This led to problems in the ODBC connector and might lead to a user confusion. A new filed flag called ON_UPDATE_NOW_FLAG is added. Constructors of the Field_timestamp set it when a field should be set to NOW on UPDATE. The get_schema_column_record function now reports whether a timestamp field will be set to NOW on UPDATE.
-
- 19 Oct, 2007 1 commit
-
-
df@pippilotta.erinye.com authored
-
- 18 Oct, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
No warning was generated when a TIMESTAMP with a non-zero time part was converted to a DATE value. This caused index lookup to assume that this is a valid conversion and was returning rows that match a comparison between a TIMESTAMP value and a DATE keypart. Fixed by generating a warning on such a truncation.
-
- 29 Jun, 2007 1 commit
-
-
anozdrin/alik@ibm. authored
-
- 04 Jun, 2007 1 commit
-
-
igor@olga.mysql.com authored
-
- 30 May, 2007 1 commit
-
-
gluh@mysql.com/eagle.(none) authored
-
- 25 May, 2007 1 commit
-
-
holyfoot/hf@mysql.com/hfmain.(none) authored
-
- 21 May, 2007 1 commit
-
-
holyfoot/hf@mysql.com/hfmain.(none) authored
result max length changed for the 'decimal' fields so test results have to be fixed
-
- 18 May, 2007 1 commit
-
-
thek@adventure.(none) authored
- Adding variable m_cached_result_type to keep the variable type consistent during the execution of a statement. - Before each result set is returned to the client the description of each column is sent as meta data. Previously the result type for a column could change if the hash variable entry changed between statements. This caused the result set of the query to alternate column types in certain cases which is not supported by MySQL client-server protocol. Example: Previously this sequence: SET @A:=1; SELECT @A:="text", @A; would return "text", "text"; After the change the SELECT returns "text", 0 The reson for this is that previously the result set from 'SELECT @A;' would always be of the type STRING, whereas now the type of the variable is taken from the last SET statement. However, 'SELECT @A:="text"' will return type of STRING since the right side of the assignment is used.
-
- 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)"
-
- 14 May, 2007 2 commits
-
-
tnurnberg@blasphemy.mysql.com 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)"
-
tnurnberg@blasphemy.mysql.com 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)"
-
- 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.
-
- 23 Mar, 2007 1 commit
-
-
monty@mysql.com/narttu.mysql.fi 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)"
-
- 02 Mar, 2007 1 commit
-
-
If we compare two items A and B, with B being (a constant) of a larger type, then A gets promoted to B's type for comparison if it's a constant, function, or CAST() column, but B gets demoted to A's type if A is a (not explicitly CAST()) column. This is counter-intuitive and not mandated by the standard. Disabling optimisation where it would be lossy so field value will properly get promoted and compared as binary string (rather than as integers).
-
- 03 Oct, 2006 2 commits
-
-
-
msvensson@shellback.(none) authored
- ie. backport from 5.1 - also update testcase error dected by new version
-
- 22 Sep, 2006 1 commit
-
-
jani@ua141d10.elisa.omakaista.fi authored
-
- 02 Aug, 2006 1 commit
-
-
svoj@may.pils.ru authored
columns Fixed confusing warning. Quoting INSERT section of the manual: ---- Inserting NULL into a column that has been declared NOT NULL. For multiple-row INSERT statements or INSERT INTO ... SELECT statements, the column is set to the implicit default value for the column data type. This is 0 for numeric types, the empty string ('') for string types, and the "zero" value for date and time types. INSERT INTO ... SELECT statements are handled the same way as multiple-row inserts because the server does not examine the result set from the SELECT to see whether it returns a single row. (For a single-row INSERT, no warning occurs when NULL is inserted into a NOT NULL column. Instead, the statement fails with an error.) ---- This is also true for LOAD DATA INFILE. For INSERT user can specify DEFAULT keyword as a value to set column default. There is no similiar feature available for LOAD DATA INFILE.
-
- 20 Jul, 2006 1 commit
-
-
The problem was that when converting a string to an exact number, rounding didn't work, because conversion didn't understand approximate numbers notation. Fix: a new function for string-to-number conversion was implemented, which is aware of approxinate number notation (with decimal point and exponent, e.g. -19.55e-1)
-
- 14 Jul, 2006 1 commit
-
-
igor@olga.mysql.com authored
DESCRIBE returned the type BIGINT for a column of a view if the column was specified by an expression over values of the type INT. E.g. for the view defined as follows: CREATE VIEW v1 SELECT COALESCE(f1,f2) FROM t1 DESCRIBE returned type BIGINT for the only column of the view if f1,f2 are columns of the INT type. At the same time DESCRIBE returned type INT for the only column of the table defined by the statement: CREATE TABLE t2 SELECT COALESCE(f1,f2) FROM t1. This inconsistency was removed by the patch. Now the code chooses between INT/BIGINT depending on the precision of the aggregated column type. Thus both DESCRIBE commands above returns type INT for v1 and t2.
-
- 13 May, 2006 1 commit
-
-
gluh@eagle.intranet.mysql.r18.ru authored
remove initialization of unsigned_flag for Item_decimal
-
- 22 Feb, 2006 1 commit
-
-
msvensson@neptunus.(none) authored
-
- 23 Jan, 2006 1 commit
-
-
ingo@mysql.com authored
Change "duplicate key" message to print key name instead of key number.
-
- 02 Dec, 2005 1 commit
-
-
gluh@eagle.intranet.mysql.r18.ru authored
-issue more correct message for incorrect date|datetime|time values -ER_WARN_DATA_OUT_OF_RANGE message is changed -added new error message
-
- 01 Dec, 2005 1 commit
-
-
gluh@eagle.intranet.mysql.r18.ru authored
SQL mode TRADITIONAL Message is chenged from 'ER_WARN_NULL_TO_NOTNULL' to 'ER_BAD_NULL_ERROR'
-
- 31 Oct, 2005 1 commit
-
-
msvensson@neptunus.(none) authored
- Cleanup of mysqltest.c before extending it
-
- 27 Sep, 2005 1 commit
-
-
pem@mysql.com authored
procedure variable Second version, after review. Keep the unsigned_flag in Item_decimal updated. Note that this also changed the result of several old test results - creating tables from decimal templates now gives unsigned columns and different sizes. (Several tests had Length > Max_length before.)
-
- 09 Sep, 2005 2 commits
-
-
gluh@eagle.intranet.mysql.r18.ru authored
-
gluh@eagle.intranet.mysql.r18.ru authored
This fix is cancellation of ChangeSet 1.2329 05/07/12 08:35:30 reggie@linux.site +8 -0 Bug 7142 Show Fields from fails using Borland's dbExpress interface The reason is we can't fix bug#7142 without breaking of existing applications/APIs that worked fine with earlier 4.1 bug 7142 is fixed in 5.0
-
- 23 Aug, 2005 1 commit
-
-
timour@mysql.com authored
* Provide backwards compatibility extension to name resolution of coalesced columns. The patch allows such columns to be qualified with a table (and db) name, as it is in 4.1. Based on a patch from Monty. * Adjusted tests accordingly to test both backwards compatible name resolution of qualified columns, and ANSI-style resolution of non-qualified columns. For this, each affected test has two versions - one with qualified columns, and one without.
-
- 12 Aug, 2005 1 commit
-
-
timour@mysql.com authored
"Process NATURAL and USING joins according to SQL:2003". * Some of the main problems fixed by the patch: - in "select *" queries the * expanded correctly according to ANSI for arbitrary natural/using joins - natural/using joins are correctly transformed into JOIN ... ON for any number/nesting of the joins. - column references are correctly resolved against natural joins of any nesting and combined with arbitrary other joins. * This patch also contains a fix for name resolution of items inside the ON condition of JOIN ... ON - in this case items must be resolved only against the JOIN operands. To support such 'local' name resolution, the patch introduces a stack of name resolution contexts used at parse time. NOTICE: - This patch is not complete in the sense that - there are 2 test cases that still do not pass - one in join.test, one in select.test. Both are marked with a comment "TODO: WL#2486". - it does not include a new test specific for the task
-
- 19 Jul, 2005 1 commit
-
-
jimw@mysql.com authored
-
- 18 Jul, 2005 1 commit
-
-
jimw@mysql.com authored
NO_ZERO_IN_DATE, and INVALID_DATES bits of SQL_MODE. (Bug #5906)
-
- 14 Jul, 2005 1 commit
-
-
konstantin@mysql.com authored
No separate typecode for MEDIUMTEXT/LONGTEXT is added, as we have no sound decision yet what typecodes and for what types are sent by the server (aka what constitutes a distinct type in MySQL).
-