mariadb/mysql-test/r/mysql_client.result

1
1
ERROR 1064 (42000) at line 3: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1
ERROR at line 1: USE must be followed by a database name
create table t17583 (a int);
insert into t17583 (a) values (0),(1),(2),(3),(4),(5),(6),(7),(8),(9);
insert into t17583 select a from t17583;
insert into t17583 select a from t17583;
insert into t17583 select a from t17583;
insert into t17583 select a from t17583;
insert into t17583 select a from t17583;
insert into t17583 select a from t17583;
insert into t17583 select a from t17583;
select count(*) from t17583;
count(*)
1280
drop table t17583;
End of 4.1 tests.
Bug#20432: mysql client interprets commands in comments do not look for client-specific commands while inside a multi-line comment. we will allow multi-comments pretty much anywhere within SQL-statements, but client-specific commands (help, use, print, ...) must be the first token in the input. client/mysql.cc: Bug#20432: mysql client interprets commands in comments mysql-test/r/mysql_client.result: Bug#20432: mysql client interprets commands in comments test client-side parsing of comments and client-specific commands mysql-test/t/mysql_client.test: Bug#20432: mysql client interprets commands in comments test client-side parsing of comments and client-specific commands 2006-07-13 09:04:06 +02:00			`1`
			`1`
			`ERROR 1064 (42000) at line 3: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1`
			`ERROR at line 1: USE must be followed by a database name`
Bug#17583: mysql drops connection when stdout is not writable When the client program had its stdout file descriptor closed by the calling shell, after some amount of work (enough to fill a socket buffer) the server would complain about a packet error and then disconnect the client. This is a serious security problem. If stdout is closed before the mysql is exec()d, then the first socket() call allocates file number 1 to communicate with the server. Subsequent write()s to that file number (as when printing results that come back from the database) go back to the server instead in the command channel. So, one should be able to craft data which, upon being selected back from the server to the client, and injected into the command stream become valid MySQL protocol to do something nasty when sent /back/ to the server. The solution is to close explicitly the file descriptor that we *printf() to, so that the libc layer and the OS layer both agree that the file is closed. BitKeeper/etc/collapsed: BitKeeper file /home/cmiller/work/mysql/bug17583/my41-bug17583/BitKeeper/etc/collapsed client/mysql.cc: If standard output is not open (specifically, if dup() of its file number fails) then we explicitly close it so that future uses of the file descriptor behave correctly for a closed file. mysql-test/r/mysql_client.result: Prove that the problem of writing SQL output to the command socket no longer exists. mysql-test/t/mysql_client.test: Prove that the problem of writing SQL output to the command socket no longer exists. 2006-10-10 00:28:06 +02:00			`create table t17583 (a int);`
			`insert into t17583 (a) values (0),(1),(2),(3),(4),(5),(6),(7),(8),(9);`
			`insert into t17583 select a from t17583;`
			`insert into t17583 select a from t17583;`
			`insert into t17583 select a from t17583;`
			`insert into t17583 select a from t17583;`
			`insert into t17583 select a from t17583;`
			`insert into t17583 select a from t17583;`
			`insert into t17583 select a from t17583;`
			`select count(*) from t17583;`
			`count(*)`
			`1280`
			`drop table t17583;`
			`End of 4.1 tests.`