Escaping change in 3.30.0 breaks existing queries

[tmwoodruff]

#2034 changes template rendering for all queries that contain escape sequences in quoted strings and make it impossible to include a single backslash in a quoted string. Prior to this change the only escape sequence that was treated as an escape within quotes was \'. After this change, backslash escapes within quoted strings apply to anything that is not a backslash.

This can break queries in unexpected ways when using a DB that supports backslash escapes in quoted strings. For example, in MySQL, SELECT 'a\t\b\nc' results in

a	b
c

This query works exactly as expected prior to 3.30. However, in 3.30.0, the query is rendered as SELECT 'atbnc', which gives a completely different result.

In fact, there's no (obvious) way to get the same query after this change. select 'a\\tb\\nc' renders as select 'a\\tb\\nc' (since \\ is not treated as an escape of a backslash (see fragment ESCAPE_IN_QUOTE)), which results in a\tb\nc.

[tmwoodruff]

I don't think there's any perfect fix here, but if SQL standard escaping is sufficient, we'd want something like

QUOTED_TEXT: '\'' (~['] | '\'\'')* '\'';
DOUBLE_QUOTED_TEXT: DOUBLE_QUOTE (~'"' | '""')+ DOUBLE_QUOTE;

This handles standard doubled-up quote escapes and allows for newlines within strings (which seem to be allowed by most dbs) but does not handle backslash-escaped quotes, which the previous implementation allowed and which many dbs accept.

I don't see any use case at all for the arbitrary escaping added in #2034.

[stevenschlansker]

Sorry this got broken :( Having this parsing code is a real drag. Will try to find some time to get a better fix in.

[tmwoodruff]

No worries. I was able to work around it easily using a custom TemplateEngine implementation.

[stevenschlansker]

I reverted the change in question for now, since it caused regressions. Still TBD on what the path forward is.

[hgschmie]

Change was backed out in 3.33.0