pub struct Dialect {
pub backslash_escapes: bool,
pub double_quoted_identifiers: bool,
pub speaks_mysql: bool,
}Expand description
v7.22 (round-13 T3) — dialect-aware tokenizer entry. With
backslash_escapes = true, plain '…' strings honour MySQL /
pre-9.1-PG backslash escapes (\' \\ \n …, the same decode
the E'…' form uses). mysqldump ALWAYS emits \'-escaped data
sections, and pg_dump ALWAYS announces PG semantics via
SET standard_conforming_strings = on — the engine flips this
flag off/on from those deterministic session signals.
How a statement’s text is to be read.
v7.39 — this was a lone bool. The second axis is ANSI_QUOTES,
which SPG behaved as though were always on: measured on MySQL 9.7.2,
SELECT "abc" answers abc, while a MySQL session on SPG answered
ERROR 1054 column "abc" does not exist. Ordinary MySQL SQL that
quotes a string with " — which a great deal of it does — failed
with an error naming a column the author never wrote.
Fields§
§backslash_escapes: bool\ escapes inside a string and # starts a comment: MySQL and
MariaDB, unless the session’s sql_mode says
NO_BACKSLASH_ESCAPES.
double_quoted_identifiers: bool"…" quotes an IDENTIFIER rather than a string literal.
PostgreSQL, always. MySQL only when ANSI_QUOTES is in
sql_mode, which its default list does not carry.
speaks_mysql: boolv7.39.2 — does the session speak MySQL at all?
The parser asked backslash_escapes this, which is a different
question: SET sql_mode='NO_BACKSLASH_ESCAPES' turned the
escapes off and took the whole grammar with it, so 7 DIV 2
stopped parsing and 'a' || 'b' went back to concatenating
where MySQL 9.7.2 answers 0.