2003-05-05 13:52:39 +02:00
#
# Some simple test of load data
#
2003-05-21 20:39:58 +02:00
--disable_warnings
2005-03-16 10:13:35 +01:00
drop table if exists t1, t2;
2003-05-21 20:39:58 +02:00
--enable_warnings
2003-05-05 13:52:39 +02:00
create table t1 (a date, b date, c date not null, d date);
2006-01-24 08:30:54 +01:00
load data infile '../std_data_ln/loaddata1.dat' into table t1 fields terminated by ',';
load data infile '../std_data_ln/loaddata1.dat' into table t1 fields terminated by ',' IGNORE 2 LINES;
2003-05-05 13:52:39 +02:00
SELECT * from t1;
2003-05-26 10:47:03 +02:00
truncate table t1;
2006-01-24 08:30:54 +01:00
load data infile '../std_data_ln/loaddata1.dat' into table t1 fields terminated by ',' LINES STARTING BY ',' (b,c,d);
2003-05-26 10:47:03 +02:00
SELECT * from t1;
2003-05-05 13:52:39 +02:00
drop table t1;
2003-05-26 10:47:03 +02:00
2003-08-22 03:07:40 +02:00
create table t1 (a text, b text);
2006-01-24 08:30:54 +01:00
load data infile '../std_data_ln/loaddata2.dat' into table t1 fields terminated by ',' enclosed by '''';
2003-08-22 03:07:40 +02:00
select concat('|',a,'|'), concat('|',b,'|') from t1;
drop table t1;
2003-12-14 05:39:52 +01:00
create table t1 (a int, b char(10));
2006-01-24 08:30:54 +01:00
load data infile '../std_data_ln/loaddata3.dat' into table t1 fields terminated by '' enclosed by '' ignore 1 lines;
2003-12-14 05:39:52 +01:00
select * from t1;
truncate table t1;
2006-01-24 08:30:54 +01:00
load data infile '../std_data_ln/loaddata4.dat' into table t1 fields terminated by '' enclosed by '' lines terminated by '' ignore 1 lines;
2003-12-14 05:39:52 +01:00
# The empty line last comes from the end line field in the file
select * from t1;
drop table t1;
2005-09-22 09:46:01 +02:00
#
# Bug #12053 LOAD DATA INFILE ignores NO_AUTO_VALUE_ON_ZERO setting
#
SET @OLD_SQL_MODE=@@SQL_MODE, @@SQL_MODE=NO_AUTO_VALUE_ON_ZERO;
create table t1(id integer not null auto_increment primary key);
insert into t1 values(0);
disable_query_log;
2006-01-24 08:30:54 +01:00
eval SELECT * INTO OUTFILE '$MYSQLTEST_VARDIR/tmp/t1' from t1;
2005-09-22 09:46:01 +02:00
delete from t1;
2006-01-24 08:30:54 +01:00
eval load data infile '$MYSQLTEST_VARDIR/tmp/t1' into table t1;
2005-09-22 09:46:01 +02:00
enable_query_log;
select * from t1;
2007-08-28 16:44:31 +02:00
remove_file $MYSQLTEST_VARDIR/tmp/t1;
2005-09-22 09:46:01 +02:00
disable_query_log;
2006-01-24 08:30:54 +01:00
eval SELECT * INTO OUTFILE '$MYSQLTEST_VARDIR/tmp/t1'
2005-09-22 09:46:01 +02:00
FIELDS TERMINATED BY '' OPTIONALLY ENCLOSED BY '' LINES TERMINATED BY '\r\n'
FROM t1;
delete from t1;
2006-01-24 08:30:54 +01:00
eval load data infile '$MYSQLTEST_VARDIR/tmp/t1' into table t1
2005-09-22 09:46:01 +02:00
FIELDS TERMINATED BY '' OPTIONALLY ENCLOSED BY '' LINES TERMINATED BY '\r\n';
enable_query_log;
select * from t1;
2007-08-28 16:44:31 +02:00
remove_file $MYSQLTEST_VARDIR/tmp/t1;
2005-09-22 09:46:01 +02:00
SET @@SQL_MODE=@OLD_SQL_MODE;
2005-09-23 14:37:22 +02:00
drop table t1;
2005-09-22 09:46:01 +02:00
2005-06-23 01:14:14 +02:00
#
# Bug #11203: LOAD DATA does not accept same characters for ESCAPED and
# ENCLOSED
#
create table t1 (a varchar(20), b varchar(20));
2006-01-24 08:30:54 +01:00
load data infile '../std_data_ln/loaddata_dq.dat' into table t1 fields terminated by ',' enclosed by '"' escaped by '"' (a,b);
2005-06-23 01:14:14 +02:00
select * from t1;
drop table t1;
2005-10-22 02:57:51 +02:00
Fixed bug #29294.
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.
sql/sql_class.h:
Fixed bug #29294.
The ESCAPE_CHARS macro constant is defined to enumerate
symbolic names of espace-sequences like '\n', '\t' etc.
The select_export::is_ambiguous_field_sep field has been added
to distinguish special values of the field_sep field from
another values (see ESCAPE_CHARS).
sql/sql_class.cc:
Fixed bug #29294.
The select_export::send_data method has been modified to
encode special values of the field_sep field by
doubling of those values instead of prepending them with a
value of the escape_char field.
Example: The SELECT 'r' INTO OUTFILE FIELDS ENCLOSED BY 'r'
now produces the 'rr' output string instead of x'5c72'
(i.e. instead of sequence of 2 bytes: \ and r).
sql/sql_load.cc:
Fixed bug #29294.
Added commentary for the READ_INFO::unescape method.
mysql-test/t/loaddata.test:
Updated test case for bug #29294.
mysql-test/r/loaddata.result:
Updated test case for bug #29294.
2007-07-03 16:37:46 +02:00
#
# Bug #29294 SELECT INTO OUTFILE/LOAD DATA INFILE with special
# characters in the FIELDS ENCLOSED BY clause
#
CREATE TABLE t1 (
id INT AUTO_INCREMENT PRIMARY KEY,
c1 VARCHAR(255)
);
CREATE TABLE t2 (
id INT,
c2 VARCHAR(255)
);
INSERT INTO t1 (c1) VALUES
('r'), ('rr'), ('rrr'), ('rrrr'),
('.r'), ('.rr'), ('.rrr'), ('.rrrr'),
('r.'), ('rr.'), ('rrr.'), ('rrrr.'),
2007-07-03 18:45:20 +02:00
('.r.'), ('.rr.'), ('.rrr.'), ('.rrrr.');
Fixed bug #29294.
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.
sql/sql_class.h:
Fixed bug #29294.
The ESCAPE_CHARS macro constant is defined to enumerate
symbolic names of espace-sequences like '\n', '\t' etc.
The select_export::is_ambiguous_field_sep field has been added
to distinguish special values of the field_sep field from
another values (see ESCAPE_CHARS).
sql/sql_class.cc:
Fixed bug #29294.
The select_export::send_data method has been modified to
encode special values of the field_sep field by
doubling of those values instead of prepending them with a
value of the escape_char field.
Example: The SELECT 'r' INTO OUTFILE FIELDS ENCLOSED BY 'r'
now produces the 'rr' output string instead of x'5c72'
(i.e. instead of sequence of 2 bytes: \ and r).
sql/sql_load.cc:
Fixed bug #29294.
Added commentary for the READ_INFO::unescape method.
mysql-test/t/loaddata.test:
Updated test case for bug #29294.
mysql-test/r/loaddata.result:
Updated test case for bug #29294.
2007-07-03 16:37:46 +02:00
SELECT * FROM t1;
2007-07-04 00:15:37 +02:00
--replace_result $MYSQLTEST_VARDIR MYSQLTEST_VARDIR
eval SELECT * INTO OUTFILE '$MYSQLTEST_VARDIR/tmp/t1' FIELDS ENCLOSED BY 'r' FROM t1;
2007-08-28 16:44:31 +02:00
cat_file $MYSQLTEST_VARDIR/tmp/t1;
Fixed bug #29294.
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.
sql/sql_class.h:
Fixed bug #29294.
The ESCAPE_CHARS macro constant is defined to enumerate
symbolic names of espace-sequences like '\n', '\t' etc.
The select_export::is_ambiguous_field_sep field has been added
to distinguish special values of the field_sep field from
another values (see ESCAPE_CHARS).
sql/sql_class.cc:
Fixed bug #29294.
The select_export::send_data method has been modified to
encode special values of the field_sep field by
doubling of those values instead of prepending them with a
value of the escape_char field.
Example: The SELECT 'r' INTO OUTFILE FIELDS ENCLOSED BY 'r'
now produces the 'rr' output string instead of x'5c72'
(i.e. instead of sequence of 2 bytes: \ and r).
sql/sql_load.cc:
Fixed bug #29294.
Added commentary for the READ_INFO::unescape method.
mysql-test/t/loaddata.test:
Updated test case for bug #29294.
mysql-test/r/loaddata.result:
Updated test case for bug #29294.
2007-07-03 16:37:46 +02:00
2007-07-04 00:15:37 +02:00
--replace_result $MYSQLTEST_VARDIR MYSQLTEST_VARDIR
eval LOAD DATA INFILE '$MYSQLTEST_VARDIR/tmp/t1' INTO TABLE t2 FIELDS ENCLOSED BY 'r';
Fixed bug #29294.
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.
sql/sql_class.h:
Fixed bug #29294.
The ESCAPE_CHARS macro constant is defined to enumerate
symbolic names of espace-sequences like '\n', '\t' etc.
The select_export::is_ambiguous_field_sep field has been added
to distinguish special values of the field_sep field from
another values (see ESCAPE_CHARS).
sql/sql_class.cc:
Fixed bug #29294.
The select_export::send_data method has been modified to
encode special values of the field_sep field by
doubling of those values instead of prepending them with a
value of the escape_char field.
Example: The SELECT 'r' INTO OUTFILE FIELDS ENCLOSED BY 'r'
now produces the 'rr' output string instead of x'5c72'
(i.e. instead of sequence of 2 bytes: \ and r).
sql/sql_load.cc:
Fixed bug #29294.
Added commentary for the READ_INFO::unescape method.
mysql-test/t/loaddata.test:
Updated test case for bug #29294.
mysql-test/r/loaddata.result:
Updated test case for bug #29294.
2007-07-03 16:37:46 +02:00
SELECT t1.id, c1, c2 FROM t1 LEFT JOIN t2 ON t1.id=t2.id WHERE c1 != c2;
SELECT t1.id, c1, c2 FROM t1 RIGHT JOIN t2 ON t1.id=t2.id WHERE c1 != c2;
2007-08-28 16:44:31 +02:00
remove_file $MYSQLTEST_VARDIR/tmp/t1;
Fixed bug #29294.
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.
sql/sql_class.h:
Fixed bug #29294.
The ESCAPE_CHARS macro constant is defined to enumerate
symbolic names of espace-sequences like '\n', '\t' etc.
The select_export::is_ambiguous_field_sep field has been added
to distinguish special values of the field_sep field from
another values (see ESCAPE_CHARS).
sql/sql_class.cc:
Fixed bug #29294.
The select_export::send_data method has been modified to
encode special values of the field_sep field by
doubling of those values instead of prepending them with a
value of the escape_char field.
Example: The SELECT 'r' INTO OUTFILE FIELDS ENCLOSED BY 'r'
now produces the 'rr' output string instead of x'5c72'
(i.e. instead of sequence of 2 bytes: \ and r).
sql/sql_load.cc:
Fixed bug #29294.
Added commentary for the READ_INFO::unescape method.
mysql-test/t/loaddata.test:
Updated test case for bug #29294.
mysql-test/r/loaddata.result:
Updated test case for bug #29294.
2007-07-03 16:37:46 +02:00
DROP TABLE t1,t2;
2005-07-28 02:22:47 +02:00
# End of 4.1 tests
2005-07-28 16:09:54 +02:00
2005-03-16 02:32:47 +01:00
#
# Let us test extended LOAD DATA features
#
create table t1 (a int default 100, b int, c varchar(60));
# we can do something like this
2006-01-24 08:30:54 +01:00
load data infile '../std_data_ln/rpl_loaddata.dat' into table t1 (a, @b) set b=@b+10, c=concat("b=",@b);
2005-03-16 02:32:47 +01:00
select * from t1;
truncate table t1;
# we can use filled fields in expressions
# we also assigning NULL value to field with non-NULL default here
2006-01-24 08:30:54 +01:00
load data infile '../std_data_ln/rpl_loaddata.dat' into table t1 (a, @b) set c= if(a is null,"oops",a);
2005-03-16 02:32:47 +01:00
select * from t1;
truncate table t1;
# we even can use variables in set clause, and missed columns will be set
# with default values
set @c:=123;
2006-01-24 08:30:54 +01:00
load data infile '../std_data_ln/rpl_loaddata.dat' into table t1 (@a, b) set c= if(@a is null,@c,b);
2005-03-16 02:32:47 +01:00
select * from t1;
# let us test side-effect of such load
2006-01-24 08:30:54 +01:00
load data infile '../std_data_ln/rpl_loaddata.dat' into table t1 (@a, @b);
2005-03-16 02:32:47 +01:00
select * from t1;
select @a, @b;
truncate table t1;
# now going to test fixed field-row file format
2006-01-24 08:30:54 +01:00
load data infile '../std_data_ln/loaddata5.dat' into table t1 fields terminated by '' enclosed by '' (a, b) set c="Wow";
2005-03-16 02:32:47 +01:00
select * from t1;
truncate table t1;
# this also should work
2006-01-24 08:30:54 +01:00
load data infile '../std_data_ln/loaddata5.dat' into table t1 fields terminated by '' enclosed by '' (a, b) set c=concat(a,"+",b,"+",@c,"+",b,"+",if(c is null,"NIL",c));
2005-03-16 02:32:47 +01:00
select * from t1;
# and this should bark
--error 1409
2006-01-24 08:30:54 +01:00
load data infile '../std_data_ln/loaddata5.dat' into table t1 fields terminated by '' enclosed by '' (a, @b);
2005-03-16 10:13:35 +01:00
# Now let us test LOAD DATA with subselect
create table t2 (num int primary key, str varchar(10));
insert into t2 values (10,'Ten'), (15,'Fifteen');
truncate table t1;
2006-01-24 08:30:54 +01:00
load data infile '../std_data_ln/rpl_loaddata.dat' into table t1 (@dummy,@n) set a= @n, c= (select str from t2 where num=@n);
2005-03-16 10:13:35 +01:00
select * from t1;
2007-02-14 14:44:34 +01:00
#
# Bug#18628 mysql-test-run: security problem
#
# It should not be possible to load from a file outside of vardir
--replace_result $MYSQLTEST_VARDIR MYSQLTEST_VARDIR
show variables like "secure_file_pri%";
--replace_result $MYSQLTEST_VARDIR MYSQLTEST_VARDIR
select @@secure_file_priv;
--error 1238
set @@secure_file_priv= 0;
# Test "load data"
truncate table t1;
--replace_result $MYSQL_TEST_DIR MYSQL_TEST_DIR
--error 1290
2007-03-16 19:56:16 +01:00
eval load data infile '$MYSQL_TEST_DIR/t/loaddata.test' into table t1;
2007-02-14 14:44:34 +01:00
select * from t1;
# Test "load_file" returns NULL
--replace_result $MYSQL_TEST_DIR MYSQL_TEST_DIR
2007-03-16 19:56:16 +01:00
eval select load_file("$MYSQL_TEST_DIR/t/loaddata.test");
2007-02-14 14:44:34 +01:00
2005-03-16 10:13:35 +01:00
# cleanup
drop table t1, t2;
2005-10-26 23:11:08 +02:00
2007-04-06 22:13:27 +02:00
#
# Bug#27586: Wrong autoinc value assigned by LOAD DATA in the
# NO_AUTO_VALUE_ON_ZERO mode
#
create table t1(f1 int);
insert into t1 values(1),(null);
create table t2(f2 int auto_increment primary key);
disable_query_log;
eval select * into outfile '$MYSQLTEST_VARDIR/tmp/t1' from t1;
SET @OLD_SQL_MODE=@@SQL_MODE, @@SQL_MODE=NO_AUTO_VALUE_ON_ZERO;
eval load data infile '$MYSQLTEST_VARDIR/tmp/t1' into table t2;
enable_query_log;
select * from t2;
2007-08-28 16:44:31 +02:00
remove_file $MYSQLTEST_VARDIR/tmp/t1;
2007-04-06 22:13:27 +02:00
SET @@SQL_MODE=@OLD_SQL_MODE;
drop table t1,t2;
2007-05-08 22:23:16 +02:00
#
# Bug#27670: LOAD DATA does not set CURRENT_TIMESTAMP default value for a
# TIMESTAMP field when no value has been provided.
#
create table t1(f1 int, f2 timestamp not null default current_timestamp);
create table t2(f1 int);
insert into t2 values(1),(2);
disable_query_log;
eval select * into outfile '$MYSQLTEST_VARDIR/tmp/t2' from t2;
eval load data infile '$MYSQLTEST_VARDIR/tmp/t2' into table t1;
enable_query_log;
2007-05-09 12:46:11 +02:00
select f1 from t1 where f2 <> '0000-00-00 00:00:00' order by f1;
2007-08-28 16:44:31 +02:00
remove_file $MYSQLTEST_VARDIR/tmp/t2;
2007-05-08 22:23:16 +02:00
delete from t1;
disable_query_log;
eval SELECT * INTO OUTFILE '$MYSQLTEST_VARDIR/tmp/t2'
FIELDS TERMINATED BY '' OPTIONALLY ENCLOSED BY '' LINES TERMINATED BY '\r\n'
FROM t2;
eval load data infile '$MYSQLTEST_VARDIR/tmp/t2' into table t1
FIELDS TERMINATED BY '' OPTIONALLY ENCLOSED BY '' LINES TERMINATED BY '\r\n';
enable_query_log;
2007-05-09 12:46:11 +02:00
select f1 from t1 where f2 <> '0000-00-00 00:00:00' order by f1;
2007-08-28 16:44:31 +02:00
remove_file $MYSQLTEST_VARDIR/tmp/t2;
2007-05-08 22:23:16 +02:00
drop table t1,t2;
2007-07-06 00:43:23 +02:00
#
# Bug#29442: SELECT INTO OUTFILE FIELDS ENCLOSED BY digit, minus sign etc
# corrupts non-string fields containing this character.
#
CREATE TABLE t1 (c1 INT, c2 TIMESTAMP, c3 REAL, c4 DOUBLE);
INSERT INTO t1 (c1, c2, c3, c4) VALUES (10, '1970-02-01 01:02:03', 1.1E-100, 1.1E+100);
SELECT * FROM t1;
--replace_result $MYSQLTEST_VARDIR MYSQLTEST_VARDIR
eval SELECT * INTO OUTFILE '$MYSQLTEST_VARDIR/tmp/t1' FIELDS ENCLOSED BY '-' FROM t1;
2007-08-28 16:44:31 +02:00
cat_file $MYSQLTEST_VARDIR/tmp/t1;
echo EOF;
2007-07-06 00:43:23 +02:00
TRUNCATE t1;
--replace_result $MYSQLTEST_VARDIR MYSQLTEST_VARDIR
eval LOAD DATA INFILE '$MYSQLTEST_VARDIR/tmp/t1' INTO TABLE t1 FIELDS ENCLOSED BY '-';
SELECT * FROM t1;
2007-08-28 16:44:31 +02:00
remove_file $MYSQLTEST_VARDIR/tmp/t1;
2007-07-06 00:43:23 +02:00
DROP TABLE t1;
2005-10-26 23:11:08 +02:00
# End of 5.0 tests