An error occurred fetching the project authors.
  1. 05 Feb, 2009 1 commit
  2. 15 Aug, 2008 1 commit
  3. 11 Jan, 2008 1 commit
  4. 06 Dec, 2007 1 commit
  5. 20 Nov, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #32400: Complex SELECT query returns correct result · 846cbf3c
      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.
      846cbf3c
  6. 13 Nov, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#30081: "ON UPDATE CURRENT_TIMESTAMP" wasn't shown by the SHOW FIELDS · 4fa7ee92
      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.
      4fa7ee92
  7. 19 Oct, 2007 1 commit
  8. 18 Oct, 2007 1 commit
  9. 29 Jun, 2007 1 commit
  10. 04 Jun, 2007 1 commit
  11. 30 May, 2007 1 commit
  12. 25 May, 2007 1 commit
  13. 21 May, 2007 1 commit
  14. 18 May, 2007 1 commit
    • thek@adventure.(none)'s avatar
      Bug#26277 User variable returns one type in SELECT @v and other for CREATE as SELECT @v · 637f85ca
      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.
      637f85ca
  15. 16 May, 2007 1 commit
    • msvensson@pilot.blaudden's avatar
      Backport of TIME->MYSQL_TIME / Y2K fixset · a65d12a8
      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)"
       
      a65d12a8
  16. 14 May, 2007 2 commits
    • tnurnberg@blasphemy.mysql.com's avatar
      Backport of TIME->MYSQL_TIME / Y2K fixset · 034aec5d
      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)"
      034aec5d
    • tnurnberg@blasphemy.mysql.com's avatar
      Backport of TIME->MYSQL_TIME / Y2K fixset · 30868bdc
      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)"
      30868bdc
  17. 26 Apr, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#27590: Wrong DATE/DATETIME comparison. · 4747fa0c
      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.
      4747fa0c
  18. 23 Mar, 2007 1 commit
    • monty@mysql.com/narttu.mysql.fi's avatar
      Removed not used define YY_MAGIC_BELOW · 19336036
      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)"
      19336036
  19. 02 Mar, 2007 1 commit
    • tnurnberg@mysql.com/sin.intern.azundris.com's avatar
      Bug #21103: DATE column not compared as DATE · f37267bb
      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).
      f37267bb
  20. 03 Oct, 2006 2 commits
  21. 22 Sep, 2006 1 commit
  22. 02 Aug, 2006 1 commit
    • svoj@may.pils.ru's avatar
      BUG#14770 - LOAD DATA INFILE doesn't respect default values for · 6c6f435b
      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.
      6c6f435b
  23. 20 Jul, 2006 1 commit
  24. 14 Jul, 2006 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #19714. · f6080640
      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.
       
      f6080640
  25. 13 May, 2006 1 commit
  26. 22 Feb, 2006 1 commit
  27. 23 Jan, 2006 1 commit
  28. 02 Dec, 2005 1 commit
  29. 01 Dec, 2005 1 commit
  30. 31 Oct, 2005 1 commit
  31. 27 Sep, 2005 1 commit
    • pem@mysql.com's avatar
      Fixed BUG#12589: Assert when creating temp. table from decimal stored · 2f3682db
      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.)
      2f3682db
  32. 09 Sep, 2005 2 commits
  33. 23 Aug, 2005 1 commit
    • timour@mysql.com's avatar
      WL#2486 - natural and using join according to SQL:2003 · e0403003
      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. 
      e0403003
  34. 12 Aug, 2005 1 commit
    • timour@mysql.com's avatar
      Implementation of WL#2486 - · a247282a
      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
      a247282a
  35. 19 Jul, 2005 1 commit
  36. 18 Jul, 2005 1 commit
  37. 14 Jul, 2005 1 commit
    • konstantin@mysql.com's avatar
      A fix and a test case for Bug#9735. · 62b8e6fd
      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).
      62b8e6fd