Description:
----[For better reports, please attach the log file after submitting. You can find it in C:\Users\Phillip\AppData\Roaming\MySQL\Workbench\log\wb.log]
I was adding comments to a field on a database I set up for educational purposes (I'm a recent graduate and trying to hone my skills a little more in this area), when I noticed that each time I would save a change to the comment, it would add put the backslashes that were only for escaping other backslashes into my comment plaintext. This leads to a cascading escalation of "leaning toothpick syndrome", and if I don't take efforts to cull the toothpicks, they quickly take over my comment string by exponential runaway.
How to repeat:
1. In the editor, bring up an instance of the create/alter table tab dialogue by right clicking, in the schema view, either a database's "Tables", or an existing table under that.
2. try creating a comment, either on the table itself or on a field of your choice, that contains backslashes or other characters that require an escape sequence. I tested with this haiku "Hel\lo work\bench devs
Lean\ing tooth\pick syn\drome stinks
please fix it quick\ly" which caused multiplying escapes on both the backslashes in the string, as well as on the linebreaks (\n).
3. When you go to apply the changes (if it's a new table, you'll need a primary key field first of course), note that the SQL code generated is correct, but that after you execute the provided query, the comment in the editor has changed and there are more backslashes than before.
4. Repeatedly make small changes and apply/execute. Each time, you get more leaning toothpicks anywhere that an escape sequence existed in the query.
Suggested fix:
the underlying problem seems to be that the editor generates queries by adding escape characters to produce the raw string, but then tries to use the raw string without performing the inverse operation on the escape sequences to take them back into their resulting characters when it LOADS the comment strings.
I think the expected behavior is to handle the escape sequences for the user going both ways, so they don't have to think about it needing these sequences in the first place. Just abstract them away for the editor. You still get a chance to double check the raw form before it executes, so nothing is lost.
In other words, the escape sequences should only appear in the real SQL, not the editor which is supposed to be abstracting it.
