The embedded parser is not capable of parsing preparable statements
containing ?:s as ordinary statements, so they have to be replaced
with something else. Replacing them with a dummy variable cannot be
done as that will affect the type of the statement. Replacing with
0 seems to be a good compromise.
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.
The capability for reading MySQL/MariaDB .test-files has now been
factored out from the compare.cc test program. That way, the
functionality can be used from other test programs as well.
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.
To prevent bugs caused by pointers having the wrong type (e.g. uint32_t
instead of uint8_t), some macros are changed into inline functions so that
the normal type-checking is performed.
The macros MYSQL_GET_ERRCODE, MYSQL_GET_STMTOK_NPARAM, MYSQL_GET_STMTOK_NATTR,
and MYSQL_GET_NATTR were not changed, because they may be too specific to
be present in a general purpose header in the first place.
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.
With 2.0.1 or earlier, if a statement contains a trailing NULL,
the statement will inside qc_sqlite.c incorrectly be assumed not
to be the one to be classified with a crash being indirectly the
result.
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.
