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.
The setting up and the initialization of the query classifier has
now been separated. The gateway explicitly sets up the query
classifier (i.e. chooses which one to use and what arguments to
provide), but the actual initialization is performed as part of
the general module initialization.
The MXS_MODULDE object now contains optinal pointers for functions
to be called att process and thread startup and shutdown. Since the
functions were added to the end, strictly speaking, all structures
would not have needed to have been modified, but better to be
explicit. In a subsequent change, these will be called.
C++ does not support flexible arrays, so for the time being C++
modules are restricted to 10 parameters. Better approach is to
factor out the parameters to a separate array and then just store
a pointer to that array in MXS_MODULE.
The MODULE_INFO is now the main object which is used by modules to convey
information to the MaxScale core. The MXS_MODULE name is more apt as it
now contains the actual module definition.
The old MODULES structure was moved into load_utils.c as an internal
implementation and was renamed so that it is not confused with the new
MODULE structure.
The modules are now declared with a common macro. This allows future
additions to the module loading process while also making the loaded
symbol name a constant.
This allows modules to only expose one entry point with a consistent
signature. In the future, this could be used to implement declarations of
module parameters.
qc_get_table_names() and qc_get_database_names() now always set
the number items, also in case of error. That is, it is now always
safe to start iterating using the number of items without first
checking the returned pointer.
When a backslash is encountered, the backslash should not be
copied but only the character after that.
For the sake of completeness, a few more characters would have
to be handled explicitly, but as the content of a string will not
affect the statement's classification there is not much point in
doing that.
Sqlite3 performs some lazy initialization, during which it internally
parses some SQL statements of its own. Earlier there was detection code
for noticing that, but it was costly and errorprone.
Now, sqlite3 is forced to perform the initialization at startup so that
we no longer need any detection code.
Together with the field names, now qc_get_field_info also returns
field usage information, that is, in what context a field is used.
This allows, for instance, the cache to take action if a a particular
field is selected (SELECT a FROM ...), but not if it is used in a
GROUP BY clause (...GROUP BY a).
This caused a significant modifications of qc_mysqlembedded that
earlier did not walk the parse-tree, but instead looped over of a
list of st_select_lex instances that, the name notwithstanding,
also contain information about other things but SELECTs. The former
approach lost all contextual information, so it was not possible
to know where a particular field was used.
Now the parse tree is walked, which means that the contextual
information is known, and thus the field usage can be updated.
Function is no longer used and it was quite unoptimal, so now
removed.
qc_get_prepare_name, qc_get_prepare_operation and qc_get_field_info
that were missing from qc_dummy added at the same time.
A HAVING clause can only refer to names that already have been mentioned
or if "SELECT *" is used. Either way, the HAVING names need not be separately
collected.
We now collect more information about a particular field and
then, if necessary, copy the data over into affected_fields if
someone is interested in that.
The comparison program is extended as well, but qc_get_fields_infos()
is not tested, because qc_mysqlembedded does not implement this yet.
This function returns more detailed information about the fields
of a statement. Supersedes qc_get_affected_fields() that will
be deprecated and removed.
Note that this function now introduced new kind of behaviour; the
returned data belongs to the GWBUF and remains valid for as long as
the GWBUF is alive. That means that unnecessary copying need not
be done.
The operation of the statement to be prepared is no longer
reported as the operation of the PREPARE statement.
Instead, when the type of the statement is
QUERY_TYPE_PREPARE_NAMED_STMT, the operation can be obtained
using qc_get_prepare_operation().
The qc_mysqlembedded implementation will be provided in a
subsequent commit.
The operation of a PREPARE statement will be that of the preparable
statement. That will make it possible to know whether an EXECUTEd
prepared statement e.g. is a SELECT or an UPDATE.
