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

[1 Nov 2004 19:03] Paul Dubois
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.
[17 Dec 2004 2:22] Ken Johanson
Could this be elevated to higher than 'Low' please? This is a critical ISO/ANSI conformance issue, breaking code portability.. Thx.
[8 Feb 2005 0:51] Jim Winstead
Fixed pushed to 5.0.
[8 Feb 2005 17:13] Paul Dubois
Mentioned in 5.0.3 change notes.

Also added NO_BACKSLASH_ESCAPES to SQL mode section.