- 10 Jul, 2006 2 commits
-
-
gkodinov/kgeorge@macbook.gmz authored
into macbook.gmz:/Users/kgeorge/mysql/work/B14553-4.1-opt
-
To make MySQL compatible with some ODBC applications, you can find the AUTO_INCREMENT value for the last inserted row with the following query: SELECT * FROM tbl_name WHERE auto_col IS NULL. This is done with a special code that replaces 'auto_col IS NULL' with 'auto_col = LAST_INSERT_ID'. However this also resets the LAST_INSERT_ID to 0 as it uses it for a flag so as to ensure that only the first SELECT ... WHERE auto_col IS NULL after an INSERT has this special behaviour. In order to avoid resetting the LAST_INSERT_ID a special flag is introduced in the THD class. This flag is used to restrict the second and subsequent SELECTs instead of LAST_INSERT_ID.
-
- 06 Jul, 2006 2 commits
-
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/mysql-4.1-opt
-
igor@olga.mysql.com authored
The implementation of the method Item_func_reverse::val_str for the REVERSE function modified the argument of the function. This led to wrong results for expressions that contained REVERSE(ref) if ref occurred somewhere else in the expressions.
-
- 04 Jul, 2006 1 commit
-
-
sergefp@mysql.com authored
-
- 29 Jun, 2006 5 commits
-
-
evgen@moonbone.local authored
into moonbone.local:/work/merge-4.1
-
tomas@poseidon.ndb.mysql.com authored
into poseidon.ndb.mysql.com:/home/tomas/mysql-4.1-main
-
tomas@poseidon.ndb.mysql.com authored
-
stewart@mysql.com authored
into mysql.com:/home/stewart/Documents/MySQL/4.1/main
-
gkodinov@mysql.com authored
into mysql.com:/home/kgeorge/mysql/4.1/warnings
-
- 28 Jun, 2006 3 commits
-
-
gkodinov@mysql.com authored
-
stewart@mysql.com authored
into mysql.com:/home/stewart/Documents/MySQL/4.1/merge
-
stewart@mysql.com authored
change default minimum to 3 bug is *very* timing dependent, unable to reproduce here, but theoretically possible.
-
- 27 Jun, 2006 5 commits
-
-
svoj@may.pils.ru authored
Produce a warning if DATA/INDEX DIRECTORY is specified in ALTER TABLE statement. Ignoring of these options is documented in the symbolic links section of the manual.
-
gkodinov@mysql.com authored
into mysql.com:/home/kgeorge/mysql/4.1/B16458
-
kroki@mysql.com authored
Dec. 31st, 9999 is still a valid date, only starting with Jan 1st 10000 things become invalid (Bug #12356)
-
gkodinov@mysql.com authored
'SELECT DISTINCT a,b FROM t1' should not use temp table if there is unique index (or primary key) on a. There are a number of other similar cases that can be calculated without the use of a temp table : multi-part unique indexes, primary keys or using GROUP BY instead of DISTINCT. When a GROUP BY/DISTINCT clause contains all key parts of a unique index, then it is guaranteed that the fields of the clause will be unique, therefore we can optimize away GROUP BY/DISTINCT altogether. This optimization has two effects: * there is no need to create a temporary table to compute the GROUP/DISTINCT operation (or the temporary table will be smaller if only GROUP is removed and DISTINCT stays or if DISTINCT is removed and GROUP BY stays) * this causes the statement in effect to become updatable in Connector/Java because the result set columns will be direct reference to the primary key of the table (instead to the temporary table that it currently references). Implemented a check that will optimize away GROUP BY/DISTINCT for queries like the above. Currently it will work only for single non-constant table in the FROM clause.
-
holyfoot@mysql.com authored
into mysql.com:/home/hf/work/mysql-4.1.clean
-
- 26 Jun, 2006 4 commits
-
-
kent@mysql.com authored
into mysql.com:/Users/kent/mysql/bk/mysql-4.1-new
-
kent@mysql.com authored
For compatibility, don't use {..,..} in pattern matching make_binary_distribution.sh: Added .dylib and .sl as shared library extensions
-
holyfoot@mysql.com authored
into mysql.com:/home/hf/work/mysql-4.1.clean
-
holyfoot@mysql.com authored
into mysql.com:/home/hf/work/mysql-4.1.clean
-
- 23 Jun, 2006 2 commits
-
-
bar@mysql.com authored
An UNIQUE KEY consisting of NOT NULL columns was displayed as PRIMARY KEY in "DESC t1". According to the code, that was intentional behaviour for some reasons unknown to me. This code was written before bitkeeper time, so I cannot check who and why made this. After discussing on dev-public, a decision was made to remove this code
-
igor@rurik.mysql.com authored
This was another manifestation of the problems fixed in the patch for bug 16674. Wrong calculation of length of the search prefix in the pattern string led here to a wrong result set for a query in 4.1. The bug could be demonstrated for any multi-byte character set.
-
- 22 Jun, 2006 4 commits
-
-
igor@rurik.mysql.com authored
Server crashed in some cases when a query required a MIN/MAX agrregation for a 'ucs2' field. In these cases the aggregation caused calls of the function update_tmptable_sum_func that indirectly invoked the method Item_sum_hybrid::min_max_update_str_field() containing a call to strip_sp for a ucs2 character set. The latter led directly to the crash as it used my_isspace undefined for the ucs2 character set. Actually the call of strip_sp is not needed at all in this situation and has been removed by the fix.
-
kent@mysql.com authored
Disable the simplistic auto dependency scan for test/bench (bug#20078)
-
holyfoot@deer.(none) authored
The AsBinary function returns VARCHAR data type with binary collation. It can cause problem for clients that treat that kind of data as different from BLOB type. So now AsBinary returns BLOB.
-
igor@rurik.mysql.com authored
execution plans in 4.1 and 5.0.
-
- 21 Jun, 2006 9 commits
-
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/mysql-4.1-opt
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-4.1-opt-mysql
-
evgen@moonbone.local authored
This bug in Field_string::cmp resulted in a wrong comparison with keys in partial indexes over multi-byte character fields. Given field a is declared as a varchar(16) collate utf8_unicode_ci INDEX(a(4)) gives us an example of such an index. Wrong key comparisons could lead to wrong result sets if the selected query execution plan used a range scan by a partial index over a utf8 character field. This also caused wrong results in many other cases.
-
svoj@may.pils.ru authored
into may.pils.ru:/home/svoj/devel/mysql/BUG20357/mysql-4.1
-
tomas@poseidon.ndb.mysql.com authored
-
svoj@may.pils.ru authored
into may.pils.ru:/home/svoj/devel/mysql/BUG20357/mysql-4.1
-
svoj@may.pils.ru authored
functions in queries Using MAX()/MIN() on table with disabled indexes (by ALTER TABLE) results in error 124 (wrong index) from storage engine. The problem was that optimizer use disabled index to optimize MAX()/MIN(). Normally it must skip disabled index and perform table scan. This patch skips disabled indexes for min/max optimization.
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/mysql-4.1-opt
-
igor@rurik.mysql.com authored
The length of the prefix of the pattern string in the LIKE predicate that determined the index range to be scanned was calculated incorrectly for multi-byte character sets. As a result of this in 4. 1 the the scanned range was wider then necessary if the prefix contained not only one-byte characters. In 5.0 additionally it caused missing some rows from the result set.
-
- 20 Jun, 2006 3 commits
-
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-4.1-opt-mysql
-
evgen@moonbone.local authored
Added test case for bug#18759 Incorrect string to numeric conversion. select.test: Added test case for bug#18759 Incorrect string to numeric conversion. item_cmpfunc.cc: Cleanup after fix for bug#18360 removal
-
ramil@mysql.com authored
into mysql.com:/usr/home/ram/work/mysql-4.1
-