fixed IN subselect with basic constant left expression
SQLCOM_CREATE_TABLE, SQLCOM_UPDATE_MULTI, SQLCOM_REPLACE_SELECT, SQLCOM_INSERT_SELECT, QLCOM_DELETE_MULTI fixed to be compatible with PS (BUG#3398, BUG#3406)
fixed multiupdate privelege check (BUG#3408)
fixed multiupdate tables check (BUG#3411)
unchecked commands now is rejected by PS protocol to avoid serever crash
fixed cleunup procedure to be compatible sith DO/SET (BUG#3393)
"MySQL server does not detect if garbage chars at the end of query":
Detect garbage chars at the end of the query or at the end of a query
for a prepared statement (which happens if mysql_real_query() or mysql_prepare()
were called with a too big 'length' parameter (bigger than the real intended
length of the query: then we receive a query + garbage characters from the
client). This resulted in garbage chars written into the binlog.
Now instead the client receives something like:
'You have an error in your SQL syntax. Check the manual that corresponds
to your MySQL server version for the right syntax to use near '!stmt'
at line 1' i.e. the server is pointing at the weird tail of the query
(this '!stmt' are the garbage chars sent by the client).
All tests pass, except mysqldump.test and ctype_utf8.test but they failed
before the patch.
Done clean-up in prep stmt API functions:
1) Removed some checks that were performed only in debug version
were making debug version more tolerable to user errors than
production (and thus caused problems for example masking some
bugs).
2) Also removed some other checks to make prep stmt API
consistent with the rest of C API (this also in line with
general politics - make checks in only those places where
errors are very common and hard to spot).
We treat Item_param whose value is not set as non-const.
This allows us to avoid use of Item_param's value (not yet existing) in
those fix_fields and fix_length_and_dec that do calculations if their
Items arguments are const. So we can call fix_fields for such items from
mysql_prepare safely.
Note:
- All test results haven't been inspected in detail to see if they are correct.
- Some result set printing seems to have the wrong field width; most notably
date/time fields and type fields (e.g. "int(4)").
- There are still some valgrind complaints, but they seem to be in assert() or
in libmysql.
