- 04 Jul, 2007 2 commits
-
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.0-opt
-
sergefp@mysql.com authored
if item_func->argument_count()==0
-
- 03 Jul, 2007 9 commits
-
-
gshchepa/uchum@gleb.loc authored
Updated test case for bug #29294.
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.0-opt
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/4.1-opt
-
gshchepa/uchum@gleb.loc authored
Test case update for bug #29294.
-
gshchepa/uchum@gleb.loc authored
Windows compilation error fix.
-
gshchepa/uchum@gleb.loc authored
The `SELECT 'r' INTO OUTFILE ... FIELDS ENCLOSED BY 'r' ' statement encoded the 'r' string to a 4 byte string of value x'725c7272' (sequence of 4 characters: r\rr). The LOAD DATA statement decoded this string to a 1 byte string of value x'0d' (ASCII Carriage Return character) instead of the original 'r' character. The same error also happened with the FIELDS ENCLOSED BY clause followed by special characters: 'n', 't', 'r', 'b', '0', 'Z' and 'N'. NOTE 1: This is a result of the undocumented feature: the LOAD DATA INFILE recognises 2-byte input sequences like \n, \t, \r and \Z in addition to documented 2-byte sequences: \0 and \N. This feature should be documented (here backspace character is a default ESCAPED BY character, in the real-life example it may be any ESCAPED BY character). NOTE 2, changed behaviour: Now the `SELECT INTO OUTFILE' statement with the `FIELDS ENCLOSED BY' clause followed by one of: 'n', 't', 'r', 'b', '0', 'Z' or 'N' characters encodes this special character itself by doubling it ('r' --> 'rr'), not by prepending it with an escape character.
-
bar@bar.myoffice.izhnet.ru authored
into mysql.com:/home/bar/mysql-work/mysql-5.0.b27345
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B28983-2-5.0-opt
-
gkodinov/kgeorge@magare.gmz authored
asserts debug binary We can't reliably check if the binary log is opened without acquiring its mutex. Fixed by removing this check.
-
- 02 Jul, 2007 5 commits
-
-
sergefp@mysql.com authored
-
lars/lthalmann@dl145j.mysql.com authored
into mysql.com:/nfsdisk1/lars/bk/mysql-5.0-rpl
-
lars/lthalmann@dl145k.mysql.com authored
into mysql.com:/nfsdisk1/lars/bk/mysql-5.0-rpl
-
lars/lthalmann@dl145j.mysql.com authored
into mysql.com:/nfsdisk1/lars/MERGE/mysql-5.0-merge
-
into mysql.com:/nfsdisk1/lars/MERGE/mysql-4.1-merge
-
- 01 Jul, 2007 3 commits
-
-
igor@olga.mysql.com authored
This bug may manifest itself not only with the queries for which the index-merge access method is chosen. It also may display itself for queries with DISTINCT. The bug was in how the Unique::get method used the merge_buffers function. To compare elements in the the queue employed by merge_buffers() it must use the buffpek_compare function rather than the function for binary comparison.
-
kostja@bodhi.(none) authored
into bodhi.(none):/opt/local/work/mysql-5.0-runtime
-
kostja@bodhi.(none) authored
-
- 30 Jun, 2007 1 commit
-
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/mysql-5.0-opt
-
- 29 Jun, 2007 9 commits
-
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.0-opt
-
gshchepa/uchum@gleb.loc authored
When a UNION statement forced conversion of an UTF8 charset value to a binary charset value, the byte length of the result values was truncated to the CHAR_LENGTH of the original UTF8 value.
-
evgen@moonbone.local authored
into moonbone.local:/mnt/gentoo64/work/29261-bug-5.0-opt-mysql
-
evgen@moonbone.local authored
spaces. When the my_strnncollsp_simple function compares two strings and one is a prefix of another then this function compares characters in the rest of longer key with the space character to find whether the longer key is greater or less. But the sort order of the collation isn't used in this comparison. This may lead to a wrong comparison result, wrongly created index or wrong order of the result set of a query with the ORDER BY clause. Now the my_strnncollsp_simple function uses collation sort order to compare the characters in the rest of longer key with the space character.
-
anozdrin/alik@ibm. authored
-
anozdrin/alik@ibm. authored
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B27333-gcov-5.0-opt
-
gkodinov/kgeorge@magare.gmz authored
query / no aggregate of subquery The optimizer counts the aggregate functions that appear as top level expressions (in all_fields) in the current subquery. Later it makes a list of these that it uses to actually execute the aggregates in end_send_group(). That count is used in several places as a flag whether there are aggregates functions. While collecting the above info it must not consider aggregates that are not aggregated in the current context. It must treat them as normal expressions instead. Not doing that leads to incorrect data about the query, e.g. running a query that actually has no aggregate functions as if it has some (and hence is expected to return only one row). Fixed by ignoring the aggregates that are not aggregated in the current context. One other smaller omission discovered and fixed in the process : the place of aggregation was not calculated for user defined functions. Fixed by calling Item_sum::init_sum_func_check() and Item_sum::check_sum_func() as it's done for the rest of the aggregate functions.
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/29247/my50-29247
-
- 28 Jun, 2007 3 commits
-
-
anozdrin/alik@ibm. authored
SHOW CREATE TABLE or SELECT FROM I_S. Actually, the bug discovers two problems: - the original query is not preserved properly. This is the problem of BUG#16291; - the resultset of SHOW CREATE TABLE statement is binary. This patch fixes the second problem for the 5.0. Both problems will be fixed in 5.1.
-
bar@mysql.com/bar.myoffice.izhnet.ru authored
Problem: like_range() returned wrong ranges for contractions (like 'ch' in Czech'). Fix: adding a special code to handle tricky cases: - contraction head followed by a wild character - full contraction - contraction part followed by another contraction part, but they are not a contraction together.
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B26642-5.0-opt
-
- 27 Jun, 2007 3 commits
-
-
malff/marcsql@weblab.(none) authored
into weblab.(none):/home/marcsql/TREE/mysql-5.0-rt-merge
-
mhansson@dl145s.mysql.com authored
into dl145s.mysql.com:/dev/shm/mhansson/my50-bug28677
-
gkodinov/kgeorge@magare.gmz authored
Thanks to Martin Friebe for finding and submitting a fix for this bug! A table with maximum number of key segments and maximum length key name would have a corrupted .frm file, due to an incorrect calculation of the complete key length. Now the key length is computed correctly (I hope) :-) MyISAM would reject a table with the maximum number of keys and the maximum number of key segments in all keys. It would allow one less than this total maximum. Now MyISAM accepts a table defined with the maximum. (This is a very minor issue.)
-
- 26 Jun, 2007 4 commits
-
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug29087
-
gshchepa/uchum@gleb.loc authored
Sometimes special 0 ENUM values was ALTERed to normal empty string ENUM values. Special 0 ENUM value has the same string representation as normal ENUM value defined as '' (empty string). The do_field_string function was used to convert ENUM data at an ALTER TABLE request, but this function doesn't care about numerical "indices" of ENUM values, i.e. do_field_string doesn't distinguish a special 0 value from an empty string value. A new copy function called do_field_enum has been added to copy special 0 ENUM values without conversion to an empty string.
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B29154-5.0-opt
-
igor@olga.mysql.com authored
a lookup into a BINARY index by a key ended with spaces. It caused an assertion abort for a debug version and wrong results for non-debug versions. The problem occurred because the function _mi_pack_key stripped off the trailing spaces from binary search keys while the function _mi_make_key did not do it when keys were inserted into the index. Now the function _mi_pack_key does not remove the trailing spaces from search keys if they are of the binary type.
-
- 25 Jun, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
into weblab.(none):/home/marcsql/TREE/mysql-5.0-rt-merge
-