'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.
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.
leads to the table corruption
New Field::store() method implemented to explicitly set thd->count_cuted_fields
before value storing, instead of (incorrectly) setting it in the CSV storage engine.
Thread row counter now properly incremented during check and repair in the CSV engine.
minor fixes to appease pushbuild.
---
Merge sin.intern.azundris.com:/home/tnurnberg/22540/50-22540
into sin.intern.azundris.com:/home/tnurnberg/22540/51-22540
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.
