There are some issues still
- With recursive CTEs qc_mysqlembedded and qc_sqlite agree upon
the real columns, but disagree on the CTE related "virtual"
columns. That's largely irrelevant though.
- qc_sqlite cannot parse "SET STATEMENT var=... FOR stmt",
but it will be classified as QUERY_TYPE_GSYSVAR_WRITE.
This is not directly CTE related.
The "parser" of compare cannot handle the following:
prepare stmt1 from "
with t as (select a from t1 where b >= 'c')
select * from t2,t where t2.c=t.a;
";
That is, that a line *not* terminating the full statement (the
line 'select * from t2,t where t2.c=t.a;' above) ends with a ';'.
Thus, it needs to be changed into e.g.
prepare stmt1 from "
with t as (select a from t1 where b >= 'c')
select * from t2,t where t2.c=t.a;";
In the context of subselects and CTEs it is somewhat difficult to
make qc_sqlite and qc_mysqlembedded to agree upon in what context
a particular field is used. As that information is not used anywhere,
a usage discrepancy is for now treated as a warning.
With this change, for a statement like
SELECT t2.a FROM t1 t2;
the affected field is reported as t1.a and not as t2.a, as it
was before.
For a statement like
SELECT t.f FROM d.t;
qc_mysqlembedded will now return "d.t.f" as the affected field,
while qc_sqlite will still return "t.f" as both implementations did
before. In qc_mysqlembedded's case that is a side-effect of the
alias handling. To get qc_sqlite to return the same (which would
be good), the table names would have to be collected in a smarter
way than they are now.
The default sql mode must now be provided explicitly when the query
classifier is setup. This is in preparation for "sql_mode" becoming
a global configuration parameter of MaxScale.
That's where it belongs as it is only the mysql client protocol that
will use it. It's a bit unfortunate that the qc test program compare
now needs to include a file from a protocol module directory, but
the fact is that the query classifier implementation and the test
programs should actually be *under* the mysql client protocol module.
Sometimes you want to know whether the parsing using different
queryclassifiers differs, irrespective of whether they agree
upon the outcome or not.
With -R it is now possible to cause a difference in the return
value of qc_parse() to be printed.
If the version if >= 10.2.3 recognized/builtin Json function should
be typed as QUERY_TYPE_READ while unrecognized ones should be typed
as QUERY_TYPE_READ | QUERY_TYPE_WRITE.
