An error occurred fetching the project authors.
  1. 21 Sep, 2005 1 commit
  2. 19 Jul, 2005 1 commit
  3. 11 Jul, 2005 2 commits
    • bar@mysql.com's avatar
      field_conv.cc: · 1042a275
      bar@mysql.com authored
        Identation fix
      1042a275
    • bar@mysql.com's avatar
      field_conv.cc: · 45fe5e74
      bar@mysql.com authored
        Bug#11591
        CHAR column with utf8 does not work properly
        (more chars than expected)
        do_cut_string didn't call well_formed_length,
        and copied all data, which was wrong in the
        case of multibyte character set.
      ctype_utf8.result, ctype_utf8.test:
        adding test case
      45fe5e74
  4. 18 Jan, 2005 1 commit
  5. 09 Nov, 2004 1 commit
  6. 08 Nov, 2004 1 commit
  7. 07 Oct, 2004 1 commit
    • dlenev@brandersnatch.localdomain's avatar
      Fix for bug #5915 "ALTER TABLE behaves differently when converting column · 1f549006
      dlenev@brandersnatch.localdomain authored
      to auto_increment in 4.1".
      Now we are enforcing NO_AUTO_VALUE_ON_ZERO mode during ALTER TABLE only
      if we are converting one auto_increment column to another auto_increment
      column (this also includes most common case when we don't do anything
      with such column).
      
      Also now when we convert some column to TIMESTAMP NOT NULL column with
      ALTER TABLE we convert NULL values to current timestamp, (as we do this
      in INSERT). One can still get old behavior by setting system TIMESTAMP
      variable to 0.
      1f549006
  8. 01 Oct, 2004 1 commit
    • dlenev@brandersnatch.localdomain's avatar
      Support for TIMESTAMP columns holding NULL values. Unlike all other · 2511990c
      dlenev@brandersnatch.localdomain authored
      column types TIMESTAMP is NOT NULL by default, so in order to have 
      TIMESTAMP column holding NULL valaues you have to specify NULL as
      one of its attributes (this needed for backward compatibility).
      
      Main changes:
      Replaced TABLE::timestamp_default_now/on_update_now members with
      TABLE::timestamp_auto_set_type flag which is used everywhere
      for determining if we should auto-set value of TIMESTAMP field 
      during this operation or not. We are also use Field_timestamp::set_time()
      instead of handler::update_timestamp() in handlers.
      2511990c
  9. 19 Aug, 2004 1 commit
  10. 18 Jun, 2004 1 commit
    • dlenev@brandersnatch.localdomain's avatar
      WL#1264 "Per-thread time zone support infrastructure". · 09ba29e5
      dlenev@brandersnatch.localdomain authored
      Added basic per-thread time zone functionality (based on public
      domain elsie-code). Now user can select current time zone
      (from the list of time zones described in system tables).
      All NOW-like functions honor this time zone, values of TIMESTAMP
      type are interpreted as values in this time zone, so now
      our TIMESTAMP type behaves similar to Oracle's TIMESTAMP WITH
      LOCAL TIME ZONE (or proper PostgresSQL type).
        
      WL#1266 "CONVERT_TZ() - basic time with time zone conversion 
      function".
        
      Fixed problems described in Bug #2336 (Different number of warnings 
      when inserting bad datetime as string or as number). This required
      reworking of datetime realted warning hadling (they now generated 
      at Field object level not in conversion functions).
        
      Optimization: Now Field class descendants use table->in_use member
      instead of current_thd macro.
      09ba29e5
  11. 06 Apr, 2004 1 commit
  12. 29 Mar, 2004 1 commit
  13. 16 Mar, 2004 2 commits
  14. 13 Dec, 2003 1 commit
  15. 11 Oct, 2003 1 commit
  16. 28 Jul, 2003 1 commit
  17. 22 Jul, 2003 1 commit
  18. 11 Jul, 2003 1 commit
  19. 01 Jul, 2003 1 commit
  20. 24 Jun, 2003 1 commit
  21. 20 Jun, 2003 1 commit
    • hf@deer.(none)'s avatar
      Proposed fix for #615 · eb901ea4
      hf@deer.(none) authored
      So now for the CREATE TABLE foo (id integer NOT NULL default 9)
      INSERT INTO foo VALUES (NULL); we get an error
      INSERT INTO foo VALUES (1), (NULL), (2); we get one warning
                and second record is set to 9
      
      Is that what we want?
      eb901ea4
  22. 30 Apr, 2003 1 commit
  23. 14 Jan, 2003 1 commit
  24. 19 Dec, 2002 1 commit
  25. 11 Dec, 2002 1 commit
  26. 03 Dec, 2002 1 commit
  27. 06 Nov, 2002 1 commit
  28. 16 Oct, 2002 1 commit
  29. 26 Jun, 2002 1 commit
  30. 21 Jun, 2002 1 commit
  31. 17 May, 2002 1 commit
  32. 12 Mar, 2002 1 commit
  33. 06 Dec, 2001 1 commit
  34. 08 Mar, 2001 1 commit
  35. 31 Jul, 2000 1 commit