- 11 Jul, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
By default MyISAM overwrites .MYD and .MYI files no DATA DIRECTORY option is used. This can lead to two tables using the same .MYD and .MYI files (that can't be dropped). To prevent CREATE TABLE from overwriting a file a new option is introduced : keep_files_on_create When this is on the CREATE TABLE throws an error if either the .MYD or .MYI exists for a MyISAM table. The option is off by default (resulting in compatible behavior).
-
- 06 Jul, 2007 1 commit
-
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug29392
-
- 05 Jul, 2007 4 commits
-
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.0-opt
-
gshchepa/uchum@gleb.loc authored
The SELECT INTO OUTFILE FIELDS ENCLOSED BY digit or minus sign, followed by the same LOAD DATA INFILE statement, used wrond encoding of non-string fields contained the enclosed character in their text representation. Example: SELECT 15, 9 INTO OUTFILE 'text' FIELDS ENCLOSED BY '5'; Old encoded result in the text file: 5155 595 ^ was decoded as the 1st enclosing character of the 2nd field; ^ was skipped as garbage; ^ ^ was decoded as a pair of englosing characters of the 1st field; ^ was decoded as traling space of the first field; ^^ was decoded as a doubled enclosed character. New encoded result in the text file: 51\55 595 ^ ^ pair of enclosing characters of the 1st field; ^^ escaped enclosed character.
-
gkodinov/kgeorge@magare.gmz authored
AsText() needs to know the maximum number of characters a IEEE double precision value can occupy to make sure there's enough buffer space. The number was too small to hold all possible values and this caused buffer overruns. Fixed by correcting the calculation of the maximum digits in a string representation of an IEEE double precision value as printed by String::qs_append(double).
-
igor@olga.mysql.com authored
This bug may manifest itself for select queries over a multi-table view that includes an ORDER BY clause in its definition. If the select list of the query contains references to the same view column with different aliases the names of the columns in the result output will be nevertheless the same, coinciding with one of the alias. The bug happened because the method Item_ref::get_tmp_table_item that was inherited by the class Item_direct_view_ref ignored the fact that the name of the view column reference must be inherited by the fields of the temporary table that was created in order to get the result rows sorted.
-
- 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 2 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
-