MySQL Bugs: #49764: mysqltest returns incorrect error if NO_BACKSLASH

Bug #49764	mysqltest returns incorrect error if NO_BACKSLASH_ESCAPES sql mode used
Submitted:	17 Dec 2009 10:01	Modified:	15 Jan 2010 12:33
Reporter:	Sveta Smirnova	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	Tools: MTR / mysql-test-run	Severity:	S3 (Non-critical)
Version:	2	OS:	Any
Assigned to:	Bjørn Munch	CPU Architecture:	Any

Description:
While trying to repeat bug #49733 I found it is not always possible to test NO_BACKSLASH_ESCAPES with MTR

How to repeat:
Run test:

set sql_mode='NO_BACKSLASH_ESCAPES';

drop table if exists searchs;
CREATE TABLE searchs(
  memb_id int NOT NULL,
  log varchar(64) NOT NULL,
  date_entered datetime NOT NULL
);

INSERT INTO searchs(memb_id,log,date_entered) VALUES(904792,'ok\','2008-11-15
04:45:13.023');

Get result:

End of line junk detected: "INSERT INTO searchs(memb_id,log,date_entered) VALUES(904792,'ok\','2008-11-15 04:45:13.023');

Which is not correct.

If use query with space after \: INSERT INTO searchs(memb_id,log,date_entered) VALUES(904792,'ok\ ','2008-11-15 04:45:13.023'); test can be used.

This has nothing to do with NO_BACKSLASH_ESCAPES, it fails without it too.

mysqltest barfs on SQL statements containing strings that end in a non-escaped backslash (which logically don't make sense without NO_BACKSLASH_ESCAPES).

I don't think I can fix this without risk of breaking existing tests, because I'd have to change the semantics of \\, \' and \" to *not* include the \ in the SQL statement.

A string that *ends* in a non-espaced \ is in any case illegal SQL unless NO_BACKSLASH_ESCAPES sql mode.

I have the workaround (why didn't I think of this before?):

Instead of 

INSERT INTO searchs(memb_id,log,date_entered) VALUES(904792,'ok\','2008-11-15
04:45:13.023');

, which is unparsable for mysqltest, do this:

let $str= 'ok\\';
eval INSERT INTO searchs(memb_id,log,date_entered) VALUES(904792,$str,'2008-11-15 04:45:13.023');

Note that the \ has to be escaped in the let command, but it will be evaluated as just one \.

Proposed workaround deemed sufficient, a fix would require a new mysqltest command to change the parsing behaviour for SQL statememnte.