The sql mode is now a property of the info object used for storing
parsing related information. It is initialized with the value of the
sql mode qc_sqlite was initialized with.
This will be further changed so that the mode can be adjusted at
runtime so that the sql mode can be the property of a session. That
is, once set it will affect all future parsing for that session.
In PL/SQL BEGIN starts a block (i.e. not a transaction). Whenever we
see that, we assume it is such a block, consume all input and set the
type to QUERY_TYPE_WRITE to ensure it goes to master.
Both 10.3 and Oracle support sequence pseudo colums and corresponding
functions. Getting the next number in the sequence is in both cases
obtained using nextval/nextval() but the current number is in Oracle
obtained using currval/currval() and in 10.3 using lastval/lastval().
These fields/functions are now ignored, in the sense that they will
not show up in the field/function infos. However, they will cause the
type mask of the statement to contain the bit QUERY_TYPE_WRITE so that
statements accessing the sequence will always be sent to the master.
Oracle SQL accepts statements like
PREPARE stmt FROM 'INSERT INTO t1 VALUES (:a,:b)';
PREPARE stmt FROM 'INSERT INTO t1 VALUES (:"a",:"b")';
That is, the variable may be surrounded by quotes.
The embedded parser of 10.3 parses things slightly differently than
how the embedded parser of earlier releases does. When comparing the
output of different query classifiers you need to be able to specify
with what qc_sqlite should be compatible with.
EXPLAIN statements are no longer parsed completely as doing so makes
it hard to modify the grammar for the needs or Oracle SQL.
Consequently, for an EXPLAIN statement you now bascially only get the
type and the operation (the newly added QUERY_OP_EXPLAIN and QUERY_OP_SHOW).
The other information is not interesting and is related to
information_schema and similar tables.
By default, only the essentials - the type and the operation - of
a statement will be collected and only if fields, tables, functions
and databases are explicitly asked for, will they be collected.
However, a statement will be parsed at most twice; if parsing is
needed a second time then all information will be collected.
If it is known that some particular information is needed, then
qc_parse() can be called explicitly to ensure it is collected
at first parsing.
It is now possible to specify what information the caller is interested
in. With this the cost for collecting information during the query parsing
that nobody is interested in can be avoided.
GCC on CentOS6 thinks there is an array-bounds error in the sqlite
code. As that code is outside our hands, it is easiest to instruct
GCC not to treat it as an error.
As every thread has a separate (in-memory) database, i.e. not
just a separate _connection_, sqlite can be compiled in singe-thread
mode, which means that there will be *no* locking.
Since the whole preparable statement will be available, it is
superfluous to provide a function using which the operation of
the preparable statement can be obtained.
This function will return the preparable statement of a PREPARE
statement as a COM_QUERY GWBUF. That is, once obtained, the normal
query classifier functions can be used for obtaining information
about the preparable statement itself.
- Only types of fixed size used in API interface
- The actual function return value specifies whether the parsing
process succeeded, while "logical" return values are returned
as out arguments.
The wrapper function currently ignores the function return value.
MXS-1070
Now both qc_mysqlembedded and qc_sqlite return the same stuff
for the same statement, and both include also operators in
addition to pure functions. Whether that is the right approach,
is still subject to debate.
However, if we want to make it possible to disable e.g. the
use of concat as in "select concat(a) from t", where a is a string,
to prevent the bypassing of the masking filter, then conceptually
it should be possible to prevent "select a+0 from t", where a is an
int, as well.
