Provide limited support for NO_BACKSLASH_ESCAPES
SQL mode
#139
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This changeset provides limited support for the
NO_BACKSLASH_ESCAPES
SQL mode. From my experience I would say this is rarely used in practice and using theNO_BACKSLASH_ESCAPES
SQL mode is usually not recommended. Accordingly, this changeset has no effect on most installations.When the
NO_BACKSLASH_ESCAPES
SQL mode is used, backslash escapes such as\'
will no longer be interpreted as a single character but instead as the two literals. This means we have to take special care when trying to escape string values that contain a'
character to avoid possible SQL injections. Instead, we can replace each'
with''
which ends up being interpreted as a single'
irrespective of whether theNO_BACKSLASH_ESCAPES
SQL mode is used. Accordingly, I've removed most unneeded escape sequences which might introduce unneeded backslashes otherwise. The updated test suite cases confirm this works across both modes.In other words, this new implementation is now somewhat closer to what MySQL implements for its
mysql_real_escape_string_quote()
function. The only known limitation is that passing a single backslash character will end up as two backslash characters. This can not be avoided with the current design, as we would have to otherwise know the actual SQL mode used (which depends on server and client side settings) or resort to work-arounds such as usingUNHEX()
andCONCAT()
. I believe the changeset provides a significant improvement over the previous situation as-is and beyond this, it's probably best to look into full prepared statement support in a future version.Link dump:
Together with #135, this resolves #131