The sqlite code is indented oddly:
In file included from query_classifier/qc_sqlite/qc_sqlite3.c:21:
sqlite-bld-3110100/sqlite3.c:98051:3: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
98051 | if( a[0]<33 ) a[0] = 33; assert( 33==sqlite3LogEst(10) );
| ^~
sqlite-bld-3110100/sqlite3.c:98051:35: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
98051 | if( a[0]<33 ) a[0] = 33; assert( 33==sqlite3LogEst(10) );
| ^~~~~~
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).
The original code for catenating an SrcList to another assumed
that the list to be catenated had only 1 element. Now works
regardless of the number of items.
When the tokenizer encounters a keyword, it sniffs whether the
last non-whitespace character before it happens to be a '.' and
if it is, the keyword is assumed to be the second part of a
qualified name.
Thus, before this commit
-- blah.
UPDATE ...
would not be parsed as KEYWORD (UPDATE) followed by stuff, but as
an ID (blah.UPDATE) followed by stuff.
With this change, newlines are no longer counted as whitespace.
A \n encounted in a string given to the query classifier test
program compare, is not converted into a newline. Makes it easier
to debug problems related to newlines.
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.
