Intended to be used from fatal signal handlers. As the statement will
be returned only while classification is in process, if a statement
is returned, it is an indication that the crash was caused by the
classification.
According to bug-report it seems that a SrcList can be NULL. This
fixes the immediate problem, but it would be good to know in what
contexts the SrcList can be NULL so that the check could be made
before calling the function instead of checking (possibly
unnecessarily at times) in the function.
GCC is smart enough to detect that the address of a local variable is
returned. Since this appears to be code used for a debug assertion, we can
just return a null pointer.
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.
With this change, both 'SET @my_id = (SELECT LAST_INSERT_ID())' and
'SET @my_id = (SELECT @@LAST_INSERT_ID)' are classified as
QUERY_TYPE_MASTER_READ|QUERY_TYPE_SESSION_WRITE|QUERY_TYPE_USERVAR_WRITE
Earlier @@last_insert_id had the QUERY_TYPE_READ bit set as well, which
indirectly caused the problems of MXS-2898.
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.
It appears that the function db_my_assert may be used but not
built into the library.
With 10.4.12 there seem to occasionally be superfluous empty
table names.
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.
