The problem was that LOAD DATA code (sql_load.cc) didn't take into
account that there may be items, representing references to other
columns. This is a usual case in views. The crash happened because
Item_direct_view_ref was casted to Item_user_var_as_out_param,
which is not a base class.
The fix is to
1) Handle references properly;
2) Ensure that an item is treated as a user variable only when
it is a user variable indeed;
3) Report an error if LOAD DATA is used to load data into
non-updatable column.
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.
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.
TIMESTAMP field when no value has been provided.
The LOAD DATA sets the current time in the TIMESTAMP field with
CURRENT_TIMESTAMP default value when the field is detected as a null.
But when the LOAD DATA command loads data from a file that doesn't contain
enough data for all fields then the rest of fields are simply set to null
without any check. This leads to no value being inserted to such TIMESTAMP
field.
Now the read_sep_field() and the read_fixed_length() functions set current
time to the TIMESTAMP field with CURRENT_TIMESTAMP default value in all cases
when a NULL value is loaded to the field.
NO_AUTO_VALUE_ON_ZERO mode.
The table->auto_increment_field_not_null variable wasn't reset after
reading a row which may lead to inserting a wrong value to the auto-increment
field to the following row.
The table->auto_increment_field_not_null variable is reset now right after a
row is being written in the read_fixed_length() and the read_sep_field()
functions.
Removed wrong setting of the table->auto_increment_field_not_null variable in
the read_sep_field() function.
- Implement --secure-file-priv=<dir> option that limits
"load_file", "LOAD DATA" and "SELECT .. INTO OUTFILE" to work
with files in specified dir.
- Use above option for mysqld in mysql-test-run.pl
set auto_increment_field_not_null to true to preserve zero values
for autoincrement fields during LOAD DATA execution if
NO_AUTO_VALUE_ON_ZERO sql mode is set
The idea is to use TABLE_LIST::lock_type for passing type of lock for
target table to mysql_load() instead of using LEX::lock_option
(which were rewritten by first subselect in SET clause).
This should also fix potential problem with LOAD DATA in SP
(it is important for them to have right lock_type in the table
list by the end of statement parsing).
Now one can use user variables as target for data loaded from file
(besides table's columns). Also LOAD DATA got new SET-clause in which
one can specify values for table columns as expressions.
For example the following is possible:
LOAD DATA INFILE 'words.dat' INTO TABLE t1 (a, @b) SET c = @b + 1;
This patch also implements new way of replicating LOAD DATA.
Now we do it similarly to other queries.
We store LOAD DATA query in new Execute_load_query event
(which is last in the sequence of events representing LOAD DATA).
When we are executing this event we simply rewrite part of query which
holds name of file (we use name of temporary file) and then execute it
as usual query. In the beggining of this sequence we use Begin_load_query
event which is almost identical to Append_file event
Don't dump data for MRG_ISAM or MRG_MYISAM tables. (Bug #1846)
Ensure that 'lower_case_table_names' is always set on case insensitive file systems. (Bug #1812)
One can now configure MySQL as windows service as a normal user. (Bug #1802)
Database names is now compared with lower case in ON clause when lower_case_table_names is set. (Bug #1736)
IGNORE ... LINES option didn't work when used with fixed length rows. (Bug #1704)
Change INSERT DELAYED ... SELECT... to INSERT .... SELECT (Bug #1983)
Safety fix for service 'mysql start' (Bug #1815)
