An error occurred fetching the project authors.
  1. 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
  2. 19 Nov, 2007 1 commit
    • kaa@polly.(none)'s avatar
      Fix for bug #32221: bug25714, mytest, mysql_client_test complaints and · 82c4059f
      kaa@polly.(none) authored
      crashes.
      
      MySQL distributions contain a number of programs that are used only by
      the MySQL test suite internally, i.e. they are not indended to be
      invoked directly by a user. As a result, such programs are not
      documented, do not have any built-in help or proper error reporting,
      which may confuse users.
      
      This patch fixes the problem with the following changes:
      - mytest, libmysqltest and all references to them were removed from the
      distribution since they are not used anymore
      - bug25714 now displays an error message when run with incorrect
      arguments or with the --help option
      - mysql_client_test now does not call abort() in case of errors,
      instead it does a clean exit() with a proper error status.
      82c4059f
  3. 23 Oct, 2007 1 commit
    • davi@moksha.local/moksha.com.br's avatar
      Bug#31669 Buffer overflow in mysql_change_user() · dac55f09
      davi@moksha.local/moksha.com.br authored
      The problem is that when copying the supplied username and
      database, no bounds checking is performed on the fixed-length
      buffer. A sufficiently large (> 512) user string can easily
      cause stack corruption. Since this API can be used from PHP
      and other programs, this is a serious problem.
      
      The solution is to increase the buffer size to the accepted
      size in similar functions and perform bounds checking when
      copying the username and database.
      dac55f09
  4. 28 Sep, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#27990: Wrong info in MYSQL_FIELD struct members when a tmp table was used. · b9e81c2a
      evgen@moonbone.local authored
      The change_to_use_tmp_fields function leaves the orig_table member of an
      expression's tmp table field filled for the new Item_field being created.
      Later orig_table is used by the Field::make_field function to provide some
      info about original table and field name to a user. This is ok for a field
      but for an expression it should be empty.
      
      The change_to_use_tmp_fields function now resets orig_table member of
      an expression's tmp table field to prevent providing a wrong info to a user.
      The Field::make_field function now resets the table_name and the org_col_name
      variables when the orig_table is set to 0.
      b9e81c2a
  5. 13 Sep, 2007 1 commit
    • tnurnberg@mysql.com/sin.intern.azundris.com's avatar
      Bug #15327: configure: --with-tcp-port option being partially ignored · 3c6ca8d6
      make sure that if builder configured with a non-standard (!= 3306)
      default TCP port that value actually gets used throughout. if they
      didn't configure a value, assume "use a sensible default", which
      will be read from /etc/services or, failing that, from the factory
      default. That makes the order of preference
      - command-line option
      - my.cnf, where applicable
      - $MYSQL_TCP_PORT environment variable
      - /etc/services (unless configured --with-tcp-port)
      - default port (--with-tcp-port=... or factory default)
      3c6ca8d6
  6. 15 Aug, 2007 1 commit
  7. 14 Aug, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#29948: Unchecked NULL pointer caused server crash. · 4bc4d834
      evgen@moonbone.local authored
      The cli_read_binary_rows function is used to fetch data from the server
      after a prepared statement execution. It accepts a statement handler and gets
      the connection handler from it. But when the auto-reconnect option is set
      the connection handler is reset to NULL after reconnection because the
      prepared statement is lost and the handler became useless. This case
      wasn't checked in the cli_read_binary_rows function and caused server crash.
      
      Now the cli_read_binary_rows function checks the connection handler to be
      not NULL and returns an error if it is.
      4bc4d834
  8. 06 Aug, 2007 1 commit
  9. 29 Jun, 2007 1 commit
  10. 15 Jun, 2007 1 commit
  11. 14 Jun, 2007 1 commit
  12. 12 Jun, 2007 2 commits
  13. 07 Jun, 2007 2 commits
  14. 06 Jun, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#28505: mysql_affected_rows() may return wrong result if CLIENT_FOUND_ROWS · b9090113
      evgen@moonbone.local authored
      flag is set.
      
      When the CLIENT_FOUND_ROWS flag is set then the server should return
      found number of rows independently whether they were updated or not.
      But this wasn't the case for the INSERT statement which always returned
      number of rows that were actually changed thus providing wrong info to
      the user.
      
      Now the select_insert::send_eof method and the mysql_insert function
      are sending the number of touched rows if the CLIENT_FOUND_ROWS flag is set.
      b9090113
  15. 25 May, 2007 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#27876 (SF with cyrillic variable name fails during execution (regression)) · 88e3abf5
      malff/marcsql@weblab.(none) authored
      The root cause of this bug is related to the function skip_rear_comments,
      in sql_lex.cc
      
      Recent code changes in skip_rear_comments changed the prototype from
      "const uchar*" to "const char*", which had an unforseen impact on this test:
        (endp[-1] < ' ')
      With unsigned characters, this code filters bytes of value [0x00 - 0x20]
      With *signed* characters, this also filters bytes of value [0x80 - 0xFF].
      
      This caused the regression reported, considering cyrillic characters in the
      parameter name to be whitespace, and truncated.
      Note that the regression is present both in 5.0 and 5.1.
      
      With this fix:
      - [0x80 - 0xFF] bytes are no longer considered whitespace.
      This alone fixes the regression.
      
      In addition, filtering [0x00 - 0x20] was found bogus and abusive,
      so that the code now filters uses my_isspace when looking for whitespace.
      
      Note that this fix is only addressing the regression affecting UTF-8
      in general, but does not address a more fundamental problem with
      skip_rear_comments: parsing a string *backwards*, starting at end[-1],
      is not safe with multi-bytes characters, so that end[-1] can confuse the
      last byte of a multi-byte characters with a characters to filter out.
      
      The only known impact of this remaining issue affects objects that have to
      meet all the conditions below:
      
      - the object is a FUNCTION / PROCEDURE / TRIGGER / EVENT / VIEW
      - the body consist of only *1* instruction, and does *not* contain a
        BEGIN-END block
      - the instruction ends, lexically, with <ident> <whitespace>* ';'?
        For example, "select <ident>;" or "return <ident>;"
      - The last character of <ident> is a multi-byte character
      - the last byte of this character is ';' '*', '/' or whitespace
      
      In this case, the body of the object will be truncated after parsing,
      and stored in an invalid format.
      
      This last issue has not been fixed in this patch, since the real fix
      will be implemented by Bug 25411 (trigger code truncated), which is caused
      by the very same code.
      The real problem is that the function skip_rear_comments is only a
      work-around, and should be removed entirely: see the proposed patch for
      bug 25411 for details.
      88e3abf5
  16. 27 Apr, 2007 1 commit
  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 Apr, 2007 1 commit
  19. 22 Mar, 2007 1 commit
  20. 19 Jan, 2007 1 commit
  21. 16 Jan, 2007 1 commit
  22. 23 Dec, 2006 1 commit
  23. 14 Dec, 2006 1 commit
    • monty@mysql.com/narttu.mysql.fi's avatar
      Fixed compiler warnings detected by option -Wshadow and -Wunused: · 88dd873d
      monty@mysql.com/narttu.mysql.fi authored
      - Removed not used variables and functions
      - Added #ifdef around code that is not used
      - Renamed variables and functions to avoid conflicts
      - Removed some not used arguments
      
      Fixed some class/struct warnings in ndb
      Added define IS_LONGDATA() to simplify code in libmysql.c
      
      I did run gcov on the changes and added 'purecov' comments on almost all lines that was not just variable name changes
      88dd873d
  24. 01 Dec, 2006 1 commit
  25. 22 Nov, 2006 3 commits
  26. 20 Nov, 2006 1 commit
    • monty@mysql.com/nosik.monty.fi's avatar
      Remove compiler warnings · e8258798
      monty@mysql.com/nosik.monty.fi authored
      (Mostly in DBUG_PRINT() and unused arguments)
      Fixed bug in query cache when used with traceing (--with-debug)
      Fixed memory leak in mysqldump
      Removed warnings from mysqltest scripts (replaced -- with #)
      e8258798
  27. 17 Nov, 2006 1 commit
  28. 25 Oct, 2006 2 commits
  29. 24 Oct, 2006 2 commits
  30. 06 Oct, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      BUG#21726: Incorrect result with multiple invocations of LAST_INSERT_ID. · ee0cebf9
      kroki/tomash@moonlight.intranet authored
      Note: bug#21726 does not directly apply to 4.1, as it doesn't have stored
      procedures.  However, 4.1 had some bugs that were fixed in 5.0 by the
      patch for bug#21726, and this patch is a backport of those fixes.
      Namely, in 4.1 it fixes:
      
        - LAST_INSERT_ID(expr) didn't return value of expr (4.1 specific).
      
        - LAST_INSERT_ID() could return the value generated by current
          statement if the call happens after the generation, like in
      
            CREATE TABLE t1 (i INT AUTO_INCREMENT PRIMARY KEY, j INT);
            INSERT INTO t1 VALUES (NULL, 0), (NULL, LAST_INSERT_ID());
      
        - Redundant binary log LAST_INSERT_ID_EVENTs could be generated.
      ee0cebf9
  31. 02 Oct, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      BUG#21726: Incorrect result with multiple invocations of LAST_INSERT_ID · 5ea8adfa
      kroki/tomash@moonlight.intranet authored
      Non-upper-level INSERTs (the ones in the body of stored procedure,
      stored function, or trigger) into a table that have AUTO_INCREMENT
      column didn't affected the result of LAST_INSERT_ID() on this level.
      
      The problem was introduced with the fix of bug 6880, which in turn was
      introduced with the fix of bug 3117, where current insert_id value was
      remembered on the first call to LAST_INSERT_ID() (bug 3117) and was
      returned from that function until it was reset before the next
      _upper-level_ statement (bug 6880).
      
      The fix for bug#21726 brings back the behaviour of version 4.0, and
      implements the following: remember insert_id value at the beginning
      of the statement or expression (which at that point equals to
      the first insert_id value generated by the previous statement), and
      return that remembered value from LAST_INSERT_ID() or @@LAST_INSERT_ID.
      
      Thus, the value returned by LAST_INSERT_ID() is not affected by values
      generated by current statement, nor by LAST_INSERT_ID(expr) calls in
      this statement.
      
      Version 5.1 does not have this bug (it was fixed by WL 3146).
      5ea8adfa
  32. 07 Sep, 2006 1 commit
  33. 31 Aug, 2006 1 commit
  34. 30 Aug, 2006 1 commit