MySQL Bugs: #6368: NO_BACKSLASH_ESCAPES doesn't always work

Bug #6368	NO_BACKSLASH_ESCAPES doesn't always work
Submitted:	1 Nov 2004 19:03	Modified:	8 Feb 2005 17:13
Reporter:	Paul DuBois	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server	Severity:	S3 (Non-critical)
Version:	5.0.x	OS:
Assigned to:	Jim Winstead	CPU Architecture:	Any

Description:
Hi!

On Oct 19, Paul DuBois wrote:
> At 10:10 +0200 10/16/04, Sergei Golubchik wrote:
> >
> >In 5.0, by a special request from SAP, vva added NO_BACKSLASH_ESCAPES
> >sql-mode. If it's set MySQL treats backslashes according to the
> >standard - that is assigns no special meaning to them.
> >
> >WL#1941
> >
> >Paul, could you please document it ?
> 
> Sure, but there's something about it that I don't understand.
> 
> mysql> select 'a\\b', 'a\\\"b', 'a''\\b', 'a''\\\"b';
> +------+--------+------+-------+
> | a\\b | a\\\"b | a'\b | a'\"b |
> +------+--------+------+-------+
> | a\\b | a\\\"b | a'\b | a'\"b |
> +------+--------+------+-------+
> 1 row in set (0.00 sec)
> 
> In each of the last two SELECT statements, note the third and fourth
> strings.  Why does '\' continue to be processed as an escape character
> when it follows a doubled instance of the character used to quote the
> string?
> 
> Or is this a bug?  I looked briefly at get_lex() in sql_lex.cc and it
> appears that found_escape is set both by '\' and by the string quoting
> character.  Effect: a doubled quote character appears to enable backslash
> processing for the rest of the string, regardless of the sql_mode value.

Right, it's a bug. Good catch ;)

How to repeat:
See above.

Could this be elevated to higher than 'Low' please? This is a critical ISO/ANSI conformance issue, breaking code portability.. Thx.

Fixed pushed to 5.0.

Mentioned in 5.0.3 change notes.

Also added NO_BACKSLASH_ESCAPES to SQL mode section.