An error occurred fetching the project authors.
  1. 03 Jun, 2007 2 commits
  2. 02 Jun, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#28494: Grouping by Item_func_set_user_var produces incorrect result. · 49346467
      evgen@moonbone.local authored
      This is an additional fix.
      Item::val_xxx methods are supposed to use original data source and
      Item::val_xxx_result methods to use the item's result field. But for the
      Item_func_set_user_var class val_xxx_result methods were mapped to val_xxx
      methods. This leads, in particular, to producing bad sort keys and thus
      wrong order of the result set of queries with group by/order by clauses.
      
      The set of val_xxx_result methods is added to the Item_func_set_user_var
      class. It's the same as the val_xxx set of method but uses the result_field
      to return a value.
      49346467
  3. 31 May, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#28494: Grouping by Item_func_set_user_var produces incorrect result. · f70ae3a6
      evgen@moonbone.local authored
      The end_update() function uses the Item::save_org_in_field() function to
      save original values of items into the group buffer. But for the 
      Item_func_set_user_var this method was mapped to the save_in_field method.
      The latter function wrongly decides to use the result_field. This leads to
      saving incorrect value in the grouping buffer and wrong result of the whole
      query.
      
      The can_use_result_field argument of the bool type is added to the
      Item_func_set_user_var::save_in_field() function. If it is set to FALSE
      then the item's result field won't be used. Otherwise it will be detected
      whether the result field will be used (old behaviour).
      Two wrapping functions for the function above are added to the 
      Item_func_set_user_var class:
      the save_in_field(Field *field, bool no_conversions) - it calls the above
      function with the can_use_result_field set to TRUE.
      the save_org_in_field(Field *field) - same, but the can_use_result_field
      is set to FALSE.
      f70ae3a6
  4. 09 Jan, 2007 1 commit
    • evgen@moonbone.local's avatar
      Fixed bug#16861: User defined variable can have a wrong value if a tmp table was · e098f736
      evgen@moonbone.local authored
      used.
      
      The Item::save_in_field() function is called from fill_record() to fill the 
      new row with data while execution of the CREATE TABLE ... SELECT statement.
      Item::save_in_field() calls val_xxx() methods in order to get values.
      val_xxx() methods do not take into account the result field. Due to this
      Item_func_set_user_var::val_xxx() methods returns values from the original
      table, not from the temporary one.
      
      The save_in_field() member function is added to the Item_func_set_user_var
      class. It detects whether the result field should be used and properly updates
      the value of the user variable.
      e098f736
  5. 04 Oct, 2006 1 commit
  6. 13 Sep, 2006 1 commit
  7. 12 Sep, 2006 1 commit
  8. 08 Sep, 2006 1 commit
  9. 22 Aug, 2006 1 commit
    • evgen@sunlight.local's avatar
      Fixed bug#16861: User defined variable can have a wrong value if a tmp table was · f17a536e
      evgen@sunlight.local authored
      used.
      
      Sorting by RAND() uses a temporary table in order to get a correct results.
      User defined variable was set during filling the temporary table and later
      on it is substituted for its value from the temporary table. Due to this
      it contains the last value stored in the temporary table.
      
      Now if the result_field is set for the Item_func_set_user_var object it 
      updates variable from the result_field value when being sent to a client.
      
      The Item_func_set_user_var::check() now accepts a use_result_field
      parameter. Depending on its value the result_field or the args[0] is used
      to get current value.
      f17a536e
  10. 09 Jun, 2006 1 commit
  11. 27 Apr, 2006 1 commit
  12. 01 Nov, 2005 1 commit
  13. 02 Aug, 2005 1 commit
  14. 25 Jul, 2005 1 commit
  15. 18 May, 2005 1 commit
  16. 30 Apr, 2005 1 commit
  17. 06 Apr, 2005 2 commits
  18. 30 Mar, 2005 1 commit
  19. 28 Mar, 2005 1 commit
  20. 16 Mar, 2005 1 commit
    • dlenev@brandersnatch.localdomain's avatar
      WL#874 "Extended LOAD DATA". · f1691140
      dlenev@brandersnatch.localdomain authored
      Now one can use user variables as target for data loaded from file
      (besides table's columns). Also LOAD DATA got new SET-clause in which
      one can specify values for table columns as expressions.
      
      For example the following is possible:
      LOAD DATA INFILE 'words.dat' INTO TABLE t1 (a, @b) SET c = @b + 1;
      
      This patch also implements new way of replicating LOAD DATA.
      Now we do it similarly to other queries.
      We store LOAD DATA query in new Execute_load_query event
      (which is last in the sequence of events representing LOAD DATA).
      When we are executing this event we simply rewrite part of query which
      holds name of file (we use name of temporary file) and then execute it
      as usual query. In the beggining of this sequence we use Begin_load_query
      event which is almost identical to Append_file event
      f1691140
  21. 23 Feb, 2005 1 commit
  22. 22 Feb, 2005 1 commit
    • bar@mysql.com's avatar
      A user variable are now always have IMPLICIT coercibility, · 89a55308
      bar@mysql.com authored
      independently from the expression it is initialized from.
      In other words, this change treats a user variable like
      a table with one column and one record. Discussed with 
      PeterG, Serg and Lars. This change also simplifies replication
      allowing not to replicate variables' coercibility.
      89a55308
  23. 17 Feb, 2005 1 commit
  24. 16 Feb, 2005 1 commit
  25. 09 Feb, 2005 1 commit
  26. 08 Feb, 2005 1 commit
  27. 07 Feb, 2005 1 commit
  28. 03 Feb, 2005 1 commit
    • guilhem@mysql.com's avatar
      WL#1062 "log charset info into all Query_log_event": · ed1696f6
      guilhem@mysql.com authored
      we store 7 bytes (1 + 2*3) in every Query_log_event.
      In the future if users want binlog optimized for small size and less safe,
      we could add --binlog-no-charset (and binlog-no-sql-mode etc): charset info
      is something by design optional (even if for now we don't offer possibility to disable it):
      it's not a binlog format change.
      We try to reduce the number of get_charset() calls in the slave SQL thread to a minimum
      by caching the charset read from the previous event (which will often be equal to the one of the current event).
      We don't use SET ONE_SHOT for charset-aware repl (we still do for timezones, will be fixed later).
      No more errors if one changes the global value of charset vars on master or slave
      (as we log charset info in all Query_log_event).
      Not fixing Load_log_event as it will be rewritten soon by Dmitri.
      Testing how mysqlbinlog behaves in rpl_charset.test.
      mysqlbinlog needs to know where charset file is (to be able to convert a charset number found
      in binlog (e.g. in User_var_log_event) to a charset name); mysql-test-run needs to pass
      the correct value for this option to mysqlbinlog.
      Many result udpates (adding charset info into every event shifts log_pos in SHOW BINLOG EVENTS).
      Roughly the same job is to be done for timezones :)
      ed1696f6
  29. 17 Jan, 2005 2 commits
  30. 16 Jan, 2005 1 commit
  31. 12 Jan, 2005 1 commit
  32. 17 Nov, 2004 2 commits
  33. 05 Nov, 2004 1 commit
    • bar@mysql.com's avatar
      user_var.result, user_var.test: · 813b2f33
      bar@mysql.com authored
        My previous change that "set @A=NULL" doesn't change charset
        fixed 'Bug #6321' as well. Prove with a new test that
        FIELD(<uservariable content NULL>, ...) now works fine too.
      813b2f33
  34. 09 Sep, 2004 1 commit
    • monty@mysql.com's avatar
      After merge fixes of merge with 4.1 that included the new arena code. · f2829d03
      monty@mysql.com authored
      Fixed (together with Guilhem) bugs in mysqlbinlog regarding --offset
      Prefix addresses with 0x for easier comparisons of debug logs
      Fixed problem where MySQL choosed index-read even if there would be a much better range on the same index
      This fix changed some 'index' queries to 'range' queries in the test suite
      Don't create 'dummy' WHERE clause for trivial WHERE clauses where we can remove the WHERE clause.
      This fix removed of a lot of 'Using where' notes in the test suite.
      Give NOTE instead of WARNING if table/function doesn't exists when using DROP IF EXISTS
      Give NOTE instead of WARNING for safe field-type conversions
      f2829d03
  35. 15 Jul, 2004 1 commit
    • monty@mysql.com's avatar
      After merge fixes · 5b3c418b
      monty@mysql.com authored
      Note: The following tests fails
      - fulltext (Sergei has promised to fix)
      - rpl_charset (Guilhem should fix)
      - rpl_timezone (Dimitray has promised to fix)
      
      Sanja needs to check out the calling of close_thread_tables() in sp_head.cc
      5b3c418b
  36. 08 Jun, 2004 1 commit
    • guilhem@mysql.com's avatar
      Correction to replication of charsets in 4.1: · b514e6a8
      guilhem@mysql.com authored
      In mysqlbinlog, there was a problem with how we escaped the content of a string user variable.
      To be perfect, we should have escaped with character_set_client. But this charset is unknown
      to mysqlbinlog. So the simplest is to print the string in hex. This is unreadable but
      100% safe with any charset (checked with Bar), no more need to bother with character_set_client.
      b514e6a8