The cast operation ignored the cases when the precision and/or the scale exceeded
the limits, 65 and 30 respectively. No errors were reported in these cases.
For some queries this may lead to an assertion abort.
Fixed by throwing errors for such cases.
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.
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).
Problem: logging queries not using indexes we check a special flag which
is set only at the server startup and is not changing with a corresponding
server variable together.
Fix: check the variable value instead of the flag.
hangs 100% cpu
Fulltext parser may fall into infinite loop when it gets illegal
multibyte sequence (or a sequence that doesn't have mapping to unicode).
Affects 5.1 only.
Problem: in case of failed 'show binlog events...' we don't inform that
the log is not in use anymore. That may confuse following 'purge logs...'
command as it takes into account logs in use.
Fix: always notify that the log is not in use anymore.
fails if a database is not selected prior.
The problem manifested itself when a user tried to
create a routine that had non-fully-qualified identifiers in its bodies
and there was no current database selected.
This is a regression introduced by the fix for Bug 19022:
The patch for Bug 19022 changes the code to always produce a warning
if we can't resolve the current database in the parser.
In this case this was not necessary, since even though the produced
parsed tree was incorrect, we never re-use sphead
that was obtained at first parsing of CREATE PROCEDURE.
The sphead that is anyhow used is always obtained through db_load_routine,
and there we change the current database to sphead->m_db before
calling yyparse.
The idea of the fix is to resolve the current database directly using
lex->sphead->m_db member when parsing a stored routine body, when
such is present.
This patch removes the need to reset the current database
when loading a trigger or routine definition into SP cache.
The redundant code will be removed in 5.1.
Problem: we don't adjust share->rows_recorded and local_saved_data_file_length
deleting rows from a CSV table, so following table check may fail.
Fix: properly adjust those values.
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.
'No database selected' is reported when calling stored procedures
Remove the offending warning introduced by the fix for Bug
25082
This minimal patch relies on the intrinsic knowledge of the fact that
mysql_change_db is never called with 'force_switch' set to TRUE
when such a warning may be needed:
* every stored routine belongs to a database (unlike, e.g., a
user defined function, which does not), so if we're activating the
database of a stored routine, it can never be NULL.
Therefore, this branch is never called for activation.
* if we're restoring the 'old' current database after routine
execution is complete, we should not issue a warning, since it's OK to
call a routine without having previously selected the current database.
TODO: 'force_switch' is an ambiguous flag, since we do not actually
have to 'force' the switch in case of stored routines at all.
When we activate the routine's database, we should perform
all the checks as in case of 'use db', and so we already do (in this
case 'force_switch' is unused).
When we load a routine into cache, we should not use mysql_change_db
at all, since there it's enough to call thd->reset_db(). We
do it this way for triggers, but code for routines is different (wrongly).
TODO: bugs are lurking in replication, since it bypasses mysql_change_db
and calls thd->[re_]set_db to set the current database.
The latter does not change thd->db_charset, thd->sctx->db_access
and thd->variables.collation_database (and this may have nasty side
effects).
These todo items are to be addressed in a separate patch, if at all.
Problem: wrong comparison with trailing space.
This problem was fixed for all other character sets under terms of
bug 7788 ""Table is full" occurs during a multitable update".
ctype-cp932.c was forgotten.
Fix: applying the same fix for ctype-cp932.c.
(see ctype-sjis.c as an example of a previously correctly fixed file)
Problem: "mysqldump" doesn exists when running "mysql-test-run --embedded-server".
Fix: changing test to use "SELECT INTO OUTFILE" instead of "mysqldump -T".
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.
