An error occurred fetching the project authors.
- 27 Jul, 2007 1 commit
-
-
holyfoot/hf@mysql.com/hfmain.(none) authored
Item_func_user doesn't calculate anything in it's val_str() method, just returns saved str_value. Though Item::save_in_field method can destroy str_value, relying on val_str() return. As a result we get the garbage stored in field. We cannot use Item::save_in_field implementation for Item_func_user, reimplement it in simpler way.
-
- 01 Apr, 2005 1 commit
-
-
monty@mysql.com authored
CAST() now produces warnings when casting a wrong INTEGER or CHAR values. This also applies to implicite string to number casts. (Bug #5912) ALTER TABLE now fails in STRICT mode if it generates warnings. Inserting a zero date in a DATE, DATETIME or TIMESTAMP column during TRADITIONAL mode now produces an error. (Bug #5933)
-
- 19 Dec, 2003 1 commit
-
-
guilhem@gbichot2 authored
* A more dynamic binlog format which allows small changes (1064) * Log session variables in Query_log_event (1063) It contains a few bugfixes (which I made when running the testsuite). I carefully updated the results of the testsuite (i.e. I checked for every one, if the difference between .reject and .result could be explained). Apparently mysql-test-run --manager is broken in 4.1 and 5.0 currently, so I could neither run the few tests which require --manager, nor check that they pass nor modify their .result. But for builds, we don't run with --manager. Apart from --manager, the full testsuite passes, with Valgrind too (no errors). I'm going to push in the next minutes. Remains: update the manual. Note: by chance I saw that (in 4.1, in 5.0) rpl_get_lock fails when run alone; this is normal at it makes assumptions on thread ids. I will fix this one day in 4.1.
-
- 18 Dec, 2003 1 commit
-
-
guilhem@gbichot2 authored
This is the main commit for Worklog tasks: * A more dynamic binlog format which allows small changes (1064) * Log session variables in Query_log_event (1063) Below 5.0 means 5.0.0. MySQL 5.0 is able to replicate FOREIGN_KEY_CHECKS, UNIQUE_KEY_CHECKS (for speed), SQL_AUTO_IS_NULL, SQL_MODE. Not charsets (WL#1062), not some vars (I can only think of SQL_SELECT_LIMIT, which deserves a special treatment). Note that this works for queries, except LOAD DATA INFILE (for this it would have to wait for Dmitri's push of WL#874, which in turns waits for the present push, so... the deadlock must be broken!). Note that when Dmitri pushes WL#874 in 5.0.1, 5.0.0 won't be able to replicate a LOAD DATA INFILE from 5.0.1. Apart from that, the new binlog format is designed so that it can tolerate a little variation in the events (so that a 5.0.0 slave could replicate a 5.0.1 master, except for LOAD DATA INFILE unfortunately); that is, when I later add replication of charsets it should break nothing. And when I later add a UID to every event, it should break nothing. The main change brought by this patch is a new type of event, Format_description_log_event, which describes some lengthes in other event types. This event is needed for the master/slave/mysqlbinlog to understand a 5.0 log. Thanks to this event, we can later add more bytes to the header of every event without breaking compatibility. Inside Query_log_event, we have some additional dynamic format, as every Query_log_event can have a different number of status variables, stored as pairs (code, value); that's how SQL_MODE and session variables and catalog are stored. Like this, we can later add count of affected rows, charsets... and we can have options --don't-log-count-affected-rows if we want. MySQL 5.0 is able to run on 4.x relay logs, 4.x binlogs. Upgrading a 4.x master to 5.0 is ok (no need to delete binlogs), upgrading a 4.x slave to 5.0 is ok (no need to delete relay logs); so both can be "hot" upgrades. Upgrading a 3.23 master to 5.0 requires as much as upgrading it to 4.0. 3.23 and 4.x can't be slaves of 5.0. So downgrading from 5.0 to 4.x may be complicated. Log_event::log_pos is now the position of the end of the event, which is more useful than the position of the beginning. We take care about compatibility with <5.0 (in which log_pos is the beginning). I added a short test for replication of SQL_MODE and some other variables. TODO: - after committing this, merge the latest 5.0 into it - fix all tests - update the manual with upgrade notes.
-