Collect all tables and SPs refered by a statement, and open all tables
with an implicit LOCK TABLES. Do find things refered by triggers and views,
we open them first (and then repeat this until nothing new is found), before
doing the actual lock tables.
are not specified in an insert. Most of these changes are actually to
clean up the test suite to either specify defaults to avoid warnings,
or add the warnings to the results. Related to bug #5986.
This fixed a bug in prepared statements when used with outher joins
Fixed a bug in SUM(DISTINCT) when used with prepared statements.
Some safety fixes in test scripts to ensure that previous test failures shouldn't affect other tests
- No RESTICT|CASCADE in DROP SP (since it's not implemented)
- Added optional "noise" to FETCH: [[NEXT] FROM]
- At least one statement required in all block constructs except BEGIN-END
(where zero is allowed)
NO SQL
CONTAINS SQL (default)
READS SQL DATA
MODIFIES SQL DATA
These are needed as hints for the replication.
(Before this, we did have the default in the mysql.proc table, but no support in the parser.)
Fixed (together with Guilhem) bugs in mysqlbinlog regarding --offset
Prefix addresses with 0x for easier comparisons of debug logs
Fixed problem where MySQL choosed index-read even if there would be a much better range on the same index
This fix changed some 'index' queries to 'range' queries in the test suite
Don't create 'dummy' WHERE clause for trivial WHERE clauses where we can remove the WHERE clause.
This fix removed of a lot of 'Using where' notes in the test suite.
Give NOTE instead of WARNING if table/function doesn't exists when using DROP IF EXISTS
Give NOTE instead of WARNING for safe field-type conversions
Althought techically not a but (as it's functioning as designed),
it was decided that the design should be changed. Some users have
a problem with dates being '0000-00-00' and the SQL standard specifies
that the modification date should be the same as the creation date
at creation.
The description is not entirerly correct. The issue was follow-up errors
where the first error is not caught - in which case it's often a system
error with errcode < 1000 (which are mapped by default to 'HY000'). In this
case the error state is different from what was assumed in the execution
loop.
at least partially. It doesn't crash or give packets out of order
any more, but it's unclear why it doesn't actually return anything
from within an SP. This should be investigated at some point, but
for the moment this will have to do. (It is a rather obscure feature... :)
It's not possible to quote the definition according to the current sql_mode
setting, so instead we use the setting stored with the SP (that's how it's
parsed anyway), and show this setting in the SHOW CREATE output.
BUG#1863: CREATE TABLE in Stored Procedure sometimes crashes on repeated calls.
BUG#2656: select with join in stored procedure: erroneous result on 2nd call.
BUG#3426: IF x IS NULL in stored procedure fails on second call within connection.
BUG#3448: Stored Procedures with inner joins possible bug.
BUG#3734: Stored procedure returns wrong rows with fulltext parameter.
BUG#3863: Stored procedure crash when incrementing variable in a loop.
(And corrected the row count output to the client after CALL)
