- 09 Dec, 2008 11 commits
-
-
Georgi Kodinov authored
-
Patrick Crews authored
-
Sergey Glukhov authored
if table has bit fields then uneven bits(if exist) are stored into null bits place. So we need to copy null bits in case of uneven bit field presence.
-
Sergey Glukhov authored
added ability for TINY[MEDIUM] text fields to be converted to greater subtype during alter if necessary(altered charset)
-
Sergey Glukhov authored
-
Alexey Kopytov authored
-
Alexey Kopytov authored
the patch manually to another tree.
-
Sergey Glukhov authored
the problem: FORMAT func max_length value was calculated incorrectly the fix: correct calculation of max_length
-
Sergey Glukhov authored
show default value for BIT field in printable format
-
Sergey Vojtovich authored
-
Alexey Kopytov authored
The reason for the failures was bug #21205 (fixed in 6.0 by dtoa, but still present in 5.0/5.1).
-
- 08 Dec, 2008 4 commits
-
-
Patrick Crews authored
-
Andrei Elkin authored
-
Alexey Kopytov authored
-
Georgi Kodinov authored
-
- 05 Dec, 2008 1 commit
-
-
Patrick Crews authored
Altered how we copy data from mysql-test/std_data on Windows to match what we are doing in 5.1 and 6.0
-
- 04 Dec, 2008 1 commit
-
-
Andrei Elkin authored
Bug #41173 rpl_packet fails sporadically on pushbuild: query 'DROP TABLE t1' failed The both issues appeared to be a race between the SQL thread executing CREATE table t1 and the IO thread that is expected to stop at the consequent big size event. The two events need serialization which is implemented. The early bug required back-porting a part fixes for bug#38350 exclusively for 5.0 version.
-
- 03 Dec, 2008 2 commits
-
-
Alexey Kopytov authored
bigint' fails on windows. Visual Studio does not take into account some x86 hardware limitations which leads to incorrect results when converting large DOUBLE values to BIGINT UNSIGNED ones. Fixed by adding a workaround for double->ulonglong conversion on Windows.
-
timothy.smith@sun.com authored
-
- 02 Dec, 2008 1 commit
-
-
Georgi Kodinov authored
-
- 01 Dec, 2008 6 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
Updated MySQL time handling code to react correctly on UTC leap second additions. MySQL functions that return the OS current time, like e.g. CURDATE(), NOW() etc will return :59:59 instead of :59:60 or 59:61. As a result the reader will receive :59:59 for 2 or 3 consecutive seconds during the leap second. This fix will not affect the values returned by UNIX_TIMESTAMP() for leap seconds. But note that when converting the value returned by UNIX_TIMESTAMP() to broken down time the correction of leap seconds will still be applied. Note that this fix will make a difference *only* if the OS is specially configured to return leap seconds from the OS time calls or when using a MySQL time zone defintion that has leap seconds. Even after this change date/time literals (or other broken down time representations) with leap seconds (ending on :59:60 or 59:61) will still be considered illegal and discarded by the server with an error or a warning depending on the sql mode. Added a test case to demonstrate the effect of the fix.
-
Georgi Kodinov authored
by using and taking out a full path.
-
Gleb Shchepa authored
TABLE_LIST doesn't free Strings in its string lists (TABLE_LIST::use_index and TABLE_liST::ignore_index), so calling c_ptr_safe() on that Strings leads to memleaks. OTOH "safe" c_ptr_safe() is not necessary there and we can replace it with c_ptr().
-
- 28 Nov, 2008 7 commits
-
-
Matthias Leich authored
Diff to actual 5.0-bugteam is revno: 2725 only
-
Gleb Shchepa authored
an error Even after the fix for bug 28701 visible behaviors of SELECT FROM a view and SELECT FROM a regular table are little bit different: 1. "SELECT FROM regular table USE/FORCE/IGNORE(non existent index)" fails with a "ERROR 1176 (HY000): Key '...' doesn't exist in table '...'" 2. "SELECT FROM view USING/FORCE/IGNORE(any index)" fails with a "ERROR 1221 (HY000): Incorrect usage of USE/IGNORE INDEX and VIEW". OTOH "SHOW INDEX FROM view" always returns empty result set, so from the point of same behaviour view we trying to use/ignore non existent index. To harmonize the behaviour of USE/FORCE/IGNORE(index) clauses in SELECT from a view and from a regular table the "ERROR 1221 (HY000): Incorrect usage of USE/IGNORE INDEX and VIEW" message has been replaced with the "ERROR 1176 (HY000): Key '...' doesn't exist in table '...'" message like for tables and non existent keys.
-
Georgi Kodinov authored
-
Georgi Kodinov authored
The SHOW VARIABLES LIKE .../SELECT @@/SELECT ... FROM INFORMATION_SCHEMA.VARIABLES were assuming that all the system variables are in system charset (UTF-8). However the variables that are settable through command line will have a different character set (character_set_filesystem). Fixed the server to remember the correct character set of basedir, datadir, tmpdir, ssl, plugin_dir, slave_load_tmpdir, innodb variables; init_connect and init_slave variables and use it when processing data.
-
Sergey Vojtovich authored
Certain boolean mode queries with truncation operator did not return matching records and calculate relevancy incorrectly.
-
Sergey Glukhov authored
-
Sergey Glukhov authored
-
- 27 Nov, 2008 7 commits
-
-
Tatiana A. Nurnberg authored
-
Sergey Glukhov authored
The bug is repeatable with latest(1.0.1) InnoDB plugin on Linux, Win, If MySQL is compiled with valgrind there are errors about using of uninitialized variable(orig_table). The fix is to set field->orig_table correct value.
-
Sergey Glukhov authored
-
Sergey Glukhov authored
enable uncacheable flag if we update a view with check option and check option has a subselect, otherwise, the check option can be evaluated after the subselect was freed as independent (See full_local in JOIN::join_free())
-
Tatiana A. Nurnberg authored
-
Sergey Glukhov authored
set DATE|DATETIME value to 0 if ALLOW_INVALID_DATES sql_mode is not enabled.
-
Sergey Glukhov authored
extended perror to enable printing of Win32 system errors
-