flaws list)
TODO:
* verify that no sequence of API calls produces SIGSEGV.
That is, verify that mysql_stmt_init -> mysql_stmt_fetch is OK,
or mysql_stmt_prepare -> mysql_stmt_fetch_column is OK and sets
meaningful error.
* remove alloc_stmt_fields call
* revise stmt->state codes and statement states.
* there are other items in prepared statements 'to fix' document.
Done:
- cleanups and comments
- revision of prepared statement error codes.
- mysql_stmt_prepare is now can always be called (that is, you can reprepare
a statement)
- new implementation of mysql_stmt_close and fetch cancellation
sigsegv protection (exp overflow)
don't return inf!
use errno=EOVERFLOW to signal an overflow (as my_strntod uses errno anyway)
if errno will be too slow, my_strtod can be changed to return overflow status in a parameter (like my_strntod does)
This ensures that my_file_info takes this the max number of files into account and one can now use --open-files-limit on windows to increase number of used files up to 2048
Added more DBUG statements
Ensure that we are comparing end space with BINARY strings
Use 'any_db' instead of '' to mean any database. (For HANDLER command)
Only strip ' ' when comparing CHAR, not other space-like characters (like \t)
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).
DROP DATABASE now assumes RAID directories are in hex. (Bug #2627)
Don't increment 'select_full_range' and similar statistics for EXPLAIN queries. (Bug #2506)
Test in configure if pthread_key_delete() exists (to fix compile problem on SCO) (Bug #2461)
when we open the HEAP table for the first time since server restart,
in hp_open(), we set a flag to propagate this info to the handler level
which then writes a DELETE FROM this_heap_table to the binlog.
It is not a perfect solution for the bug, because between the server start and
the first open of the table, the slave still had old data in his table so
a SELECT on the slave may show wrong content. But if there is a --init-file
to populate the HEAP table on master as startup, then this is a safe fix
(I'll put a note about init-file in the HEAP section of the manual).
