An error occurred fetching the project authors.
- 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.
-
- 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
-
- 30 May, 2007 1 commit
-
-
gluh@mysql.com/eagle.(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
-
- 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)"
-
- 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.
-
- 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 1 commit
-
-
msvensson@shellback.(none) authored
- ie. backport from 5.1 - also update testcase error dected by new version
-
- 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
-
- 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).
-
- 12 Jul, 2005 1 commit
-
-
reggie@linux.site authored
The problem here is that columns that have an especially long type such as an enum type with many options would be longer than 40 chars but the type column returned from show columns always was defined as varchar(40). This is fixed in 5.0 using info schema.
-
- 20 Jun, 2005 1 commit
-
-
msvensson@neptunus.(none) authored
- Print warning that says display width is not supported for datatype TIMESTAMP, if user tries to create a TIMESTAMP column with display width. - Use display width for TIMESTAMP only in type_timestamp test to make sure warning is displayed correctly.
-
- 14 Jun, 2005 1 commit
-
-
mskold@mysql.com authored
-
- 07 Jun, 2005 2 commits
-
-
igor@rurik.mysql.com authored
Fixed bug #9899: erronious NOT_NULL flag for some attributes in the EXPLAIN table.
-
konstantin@mysql.com authored
error for LIMIT placeholder". The patch adds grammar support for LIMIT ?, ? and changes the type of ST_SELECT_LEX::select_limit,offset_limit from ha_rows to Item*, so that it can point to Item_param.
-
- 05 May, 2005 1 commit
-
-
holyfoot@hf-ibm.(none) authored
-
- 30 Mar, 2005 1 commit
-
-
msvensson@neptunus.(none) authored
- Add function Item_param::fix_fields which will update any subselect they are part of and indicate that the subsleect is not const during prepare phase, and thus should not be executed during prepare.
-
- 23 Mar, 2005 1 commit
-
-
serg@serg.mylan authored
corrected number of fields for --enable_metadata sql/sql_union.cc fixed a apparent typo in assert
-
- 10 Feb, 2005 1 commit
-
-
monty@mysql.com authored
After merge fixes Don't give duplicate warnings for some ::store() functions
-
- 08 Feb, 2005 1 commit
-
-
hf@deer.(none) authored
-
- 18 Jan, 2005 2 commits
-
-
bar@mysql.com authored
-
bar@mysql.com authored
not default_charset_into. It fixes the problem that in some cases numbers where treated as CHAR(N), not as BINARY(N), e.g. wrong 'charsetnr' when sent to the client side. 2. IFNULL didn't aggregate argument charsets and collations, so IFNULL(1,'a') produced a CHAR(N). Now produces a BINARY(N). 3. SELECT PROCEDURE ANALIZE now returns BINARY columns, which is much better than it worked previously: CHAR with the default character set. But in the future it's worth to fix the fields 'Field_name' and 'Optimal_fieldtype' to use UTF8, and 'Min_value' and 'Max_value' to inherit their charsets from the original items. But it is not important, and BINARY(N) is OK for now. 4. Tests were fixed accordingly. No new tests were made, as the old onces cover everything.
-
- 30 Dec, 2004 2 commits
-
-
monty@mysql.com authored
-
dlenev@brandersnatch.localdomain authored
correctly even with zero month and day" and bug #7515 "from_unixtime(0) now returns NULL instead of the Epoch" into 4.1 tree.
-
- 17 Dec, 2004 1 commit
-
-
mleich@mysql.com authored
longer available for most storage engines. Therefore column c18 BIT is switched TINYINT .
-
- 13 Dec, 2004 1 commit
-
-
mleich@mysql.com authored
ps-modify1 used the user variables @1, @2, @100 set within ps_query and ps_modify. That architecture was wrong, because the dependence of ps_modify1 on ps_query and ps_modify makes the test script maintenance and the use of these test cases during bug fixing/ debugging of single sub test cases very uncomfortable. Therefore these user variables (@1, @2, @100) are also set within ps-modify1. The result files of the test cases ps_2myisam, ps_3innodb, ps_4heap, ps_6bdb, ps_7ndb will be affected by that change and show 3 additional lines, but nothing else will change.
-
- 08 Dec, 2004 1 commit
-
-
bar@mysql.com authored
- CREATE TABLE t1 SELECT BINARY 'literal' now creates a VARBINARY() column, not a BINARY().
-