Added a case for bug #4976 when one of the inner tables is empty.
select.result, join.result:
Reversed the previous change of the erronious fix for bug #4976.
sql_select.cc:
The previous fix for bug 4976 was reversed as it
erroniously converted an outer join into an innner join
when on_expression does not refer to outer tables.
This is not valid if inner tables return an empty set.
Setting dependency on outer tables was added for the above cases.
To fix the crash in the test case of bug #4976
a guard was added that blocks running the crashing code for
nested outer joins.
Fixed bug #4976.
join_nested.result, join_nested.test:
Added a test case for bug #4976.
sql_select.cc:
Applied conversion from an outer join to an inner join
when the on expression does not depend on the outer table.
It fixed bug #4976.
Added a test case for bug #4922.
sql_select.cc:
Blocked an optimization performed by join_read_const_table when
applied to an inner table of a nested outer join.
It was done to fix bug #4922.
sql_yacc.yy:
Fixed a typo bug in the rule for join_table.
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.
- client side part is simple and may be considered stable
- server side part now just joggles with THD state to save execution
state and has no additional locking wisdom.
Lot's of it are to be rewritten.
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... :)
new tests to ensure that prepared statement *really* work
(and that MySQL not picks up some number from arbitrary location
that happens to match the parameter's value)
client code and replication slave code, as far as LOAD DATA INFILE and
other queries' execution is concerned. Duplication of code leads to
replication bugs, because the replication duplicate lags much behind.
Fix for 2 Valgrind errors on slave replicating LOAD DATA INFILE
- one serious (causing a random test failure in rpl_loaddata in 5.0)
- one not serious (theoretically a bug but not dangerous): uninited thd->row_count