In the case of qc_sqlite, it is done "precisely", while in the
case of qc_mysqlembedded rather bluntly. Not time well spent
to figure out exactly which pointer chains need to be walked.
To make it possible to have more tokens than 255.
Parsers operators (i.e. tokens) is one thing and opcodes
for the virtual machine of sqlite3 is another. Unfortunately
they are not completely separate, but some of the opcodes
in <build-directory>/opcodes.h are the same as the tokens in
<build-directory>/parse.h. And while the parser tokens are now
16-bit, the VM opcodes are 8-bit. However, this is probably not
a problem even if some of the parser tokens that are duplicated
in the opcodes are > 256 as we only use sqlite3 for parsing and
not for executing anything (on the sqlite3 VM).
Problem was that 'handler' is a keyword. To make it work,
the keyword must be listed as one of those that turns into
an id where it cannot be used as a keyword.
Lemon (the sqlite parser generator) destructors are needed for
all rules that return dynamically allocated structures. Otherwise
there may be leaks if a statement is not completely parsed.
DIV and MOD are now also accepted instead of / and % respectively.
MOD is a keyword but (in principle incorrectly) decays into an id
when used in some other context. That is so that it will be
parser by the general function rule ("id ( ... )"). If used
incorrectly, the server will later reject.
In the tokenizer we will now recognize the character set names
of MariaDB and return a specific token for those. However, where
a character set name is not expected, it will automatically be
treated as an identifier.
Note that when the character set name is explicitly specified
for a literal string, the name must be prefixed with an underscore.
That is, if the character set name is "latin1", when used when
specifying a literal string, it's used as "_latin1 'a'".
Note that this does not fix the sqlite3 bug causing a leak, but
since the statement will now correctly be parsed, the leak will
not manifest itself.
Originally, the sqlite installation was imported into the MaxScale
repository in the one gigantic MaxScale 1.4 -> 2.0 commit.
Consequently, there is no import commit to compare to if you want
to extract all MaxScale specific changes. To make it simpler in the
future, sqlite will now be imported in a commit of its own.
The purpose is to recognize e.g. /_utf8mb4 0xD091D092D093/ as
a valid string. The rule actually accepts /id integer/, but in
case the statement is something else but an '_' immediately
followed by a character set, followed by a hex number, it will
be rejected by the server so no harm done.
With this change, a parenthesized top-level SELECT, such as
"(SELECT f FROM t)" will be fully parsed. Before this change,
the statement was classified as invalid and would thus have
been sent to the master.
With this change also statements like
(SELECT f FROM t1) UNION (SELECT f FROM t2)
will be correctly classified, although only partially parsed.
With these changes
SET @saved_cs_client= @@character_set_client;
will be classified as QUERY_TYPE_USERVAR_WRITE and
SELECT 1 AS c1 FROM t1 ORDER BY ( SELECT 1 AS c2 FROM
t1 GROUP BY GREATEST(LAST_INSERT_ID(), t1.a) ORDER BY
GREATEST(LAST_INSERT_ID(), t1.a) LIMIT 1);
will be classified as QUERY_TYPE_READ|QUERY_TYPE_MASTER_READ
With this change, a parenthesized top-level SELECT, such as
"(SELECT f FROM t)" will be fully parsed. Before this change,
the statement was classified as invalid and would thus have
been sent to the master.
With this change also statements like
(SELECT f FROM t1) UNION (SELECT f FROM t2)
will be correctly classified, although only partially parsed.
When a statement like 'DESCRIBE tbl' is classified, the table
name will now be available so that a router can check whether the
table is a temporary one. In that case, the statement must be sent
to the master.
RESET QUERY CACHE is reported to be a session command, which will
cause it to be sent to all servers. RESET [MASTER|SLAVE] are
classified as write, which will cause them to be sent to the master.
It could be argued that RESET [MASTER|SLAVE] should cause an error
to be sent to the client.
Recognize the XA keyword and classify the statement as write.
Needs to be dealt with explicitly as sqlite3 assumes there are
no keywords starting with the letter X.
A statement like
SELECT ... INTO OUTFILE|DUMPFILE ...
is now classified as a QUERY_TYPE_WRITE, instead of as
QUERY_TYPE_GSYSVAR_WRITE so that it will be sent only to the
master.
SELECT...FOR UPDATE locks the rows for update, but only if
autocommit==0 or a transaction is active, so in principle even if
it were classified as READ it'd still be sent to master when it
actually matters.
However, even if autocommit==1 and/or no transaction is active, a
slave in read only mode will reject the statement if the user is
subject to the read only restriction (a user with super privileges
is not), which might be considered a server bug. By classifying the
statement as a write, it'll be sent to master and always succeed.
The two operations return different types of results and need to be
treated differently in order for them to be handled correctly in 2.2.
This fixes the unexpected internal state errors that happened in all 2.2
versions due to a wrong assumption made by readwritesplit. This fix is not
necessary for newer versions as the LOAD DATA LOCAL INFILE processing is
done with a simpler, and more robust, method.
Earlier only "SELECT NEXT VALUE FOR SEQ" was parsed
properly, while "SELECT PREVIOUS VALUE FOR SEQ" was not.
Now the latter statement is also parsed properly.
ENGINE is a keyword but not a reserved word, so it must
silently convert into an identifier if it is used in a
context where it cannot be used as a keyword.
"INTERVAL N <unit>" is now handled as an expression in itself and
as asuch will cause both statements such as
"SELECT '2008-12-31 23:59:59' + INTERVAL 1 SECOND;"
and
"select id from db2.t1 where DATE_ADD("2017-06-15", INTERVAL 10 DAY) < "2017-06-15";"
to be handled correctly. The compare test program contains some
heuristic checking, as the the embedded parser will in all cases
report date manipulation as the use of the add_date_interval()
function.
Basically it would be trivial to report far more operations
explicitly, but for the fact that the values in qc_query_op_t
currently, quite unnecessarily, form a bitmask.
In 2.2 that is no longer the case, so other operations will be
added there.
