If some string literals are used in DDL, they might have `Character Set Introducers`
https://dev.mysql.com/doc/refman/8.0/en/charset-introducer.html
f.e. _utf8mb4'1' which is not parsable by current ParserStringLiteral.
Since we use utf8 by default, suggesting to automatically convert the string literals to utf8
before executing the query and avoid any charset introducers there.
Conversion from utf8 to utf8 is not needed and skipped.
Also it might convert double quotes to single quotes if any
which might solve issues with COMMENT and empty string literals "" in DEFAULT expressions.
SELECT _latin1"abc"; -- might be also valid for MySQL
... DEFAULT "",
... COMMENT "abc"
Currently no DEFAULT expressions are supported, not parsable at all,
but using this MR it allows to parse the expressions together with double quotes as string literals.
Since ClickHouse does not support unquoted utf-8 strings but MySQL does.
Instead of fixing Lexer to recognize utf-8 chars as TokenType::BareWord,
suggesting to quote all unrecognized tokens before applying any DDL.
Actual parsing and validating the syntax will be done by particular Parser.
If there is any TokenType::Error, the query is unable to be parsed anyway.
Quoting such tokens can provide the support of utf-8 names.
See `tryQuoteUnrecognizedTokens` and `QuoteUnrecognizedTokensTest`.
mysql> CREATE TABLE 道.渠(...
is converted to
CREATE TABLE `道`.`渠`(...
Also fixed the bug with missing * while doing SELECT in full sync because db or table name are back quoted when not needed.
1. Dropped support for DatabaseOrdinary for MaterializeMySQL. It
is marked as experimental, and dropping support makes the code
more maintaible, and speeds up integration tests by 50%.
2. Get rid of thread name logic for StorageMaterializeMySQL wrapping,
use setInternalQuery instead (similar to MaterializedPostgreSQL).
We would update the set of seen GTIDs as soon as we saw a GTID_EVENT,
which arrives before a transaction. This would mostly work fine, but
if we lost the connection to MySQL in the middle of a large transaction
we would persist that the transaction had been processed as soon as the
transaction had started. When the connection was reestablished, we
would not process the transaction again, which meant that we only
applied parts of it.
Fix this by updating the seen GTIDs at the end of the transaction
instead.
