partitioned table

Trying INSERT DELAYED on a partitioned table, that has not been
used right before, crashes the server. When a table is used for
select or update, it is kept open for some time. This period I
mean with "right before".

Information about partitioning of a table is stored in form of
a string in the .frm file. Parsing of this string requires a
correctly set up lexical analyzer (lex). The partitioning code
uses a new temporary instance of a lex. But it does still refer
to the previously active lex. The delayd insert thread does not
initialize its lex though...

Added initialization for thd->lex before open table in the delayed
thread and at all other places where it is necessary to call
lex_start() if all tables would be partitioned and need to parse
the .frm file.

into  stella.local:/home2/mydev/mysql-5.1-bug15522

into  mattiasj-laptop.(none):/home/mattiasj/clones/mysql-5.1-bug30484

into  stella.local:/home2/mydev/mysql-5.1-bug15522

into  stella.local:/home2/mydev/mysql-5.0-bug15522

Added test case.
The fix for Bug#20662 does also fix this one.

into  xiphis.org:/anubis/antony/work/p1-bug31382.1.merge-5.1

into  xiphis.org:/anubis/antony/work/p1-bug31382.1.merge-5.1

  "Disabled plugin is provoking Valgrind error"
  If there are any auto-alloced string plug-in options, memory is
  allocated during the call for handle_options(). We must free this
  memory if we are not installing the plug-in.

Two cases in ha_partition::extra() was missing
(HA_EXTRA_DELETE_CANNOT_BATCH and HA_EXTRA_UPDATE_CANNOT_BATCH)
which only is currently used by NDB (which not uses ha_partition)

into  mysql.com:/home/svoj/devel/mysql/BUG30583/mysql-5.1-engines

into  stella.local:/home2/mydev/mysql-5.1-axmrg

into  stella.local:/home2/mydev/mysql-5.1-axmrg

into  stella.local:/home2/mydev/mysql-5.0-axmrg

into  stella.local:/home2/mydev/mysql-5.0-axmrg

into  stella.local:/home2/mydev/mysql-4.1-axmrg

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.1-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.1-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build

into  production.mysql.com:/usersnfs/jperkin/bk/build-5.1

cmake list are auto-generated and thus still required.  Correct fix
not yet known.

into  mysql.com:/home/gluh/MySQL/Merge/5.1-opt

into  mysql.com:/home/gluh/MySQL/Merge/5.1-opt

into  mysql.com:/home/gluh/MySQL/Merge/5.1-opt

added get_field_default_value() function which obtains default value from the field
(used in store_create_info() & get_schema_column_record() functions)

into  magare.gmz:/home/kgeorge/mysql/autopush/B30639-5.1-opt

 The parser uses ulonglong to store the LIMIT number. This number
 then is stored into a variable of type ha_rows. ha_rows is either
 4 or 8 byte depending on the BIG_TABLES define from config.h
 So an overflow may occur (and LIMIT becomes zero) while storing an
 ulonglong value in ha_rows.
 Fixed by :
  1. Using the maximum possible value for ha_rows on overflow
  2. Defining BIG_TABLES for the windows builds (to match the others) 

into  mysql.com:/home/gluh/MySQL/Merge/5.1-opt

into  mysql.com:/home/gluh/MySQL/Merge/5.1-opt

into  mysql.com:/home/gluh/MySQL/Merge/5.0-opt

  Post-merge fix.

into  devsrv-b.mysql.com:/data0/gshchepa/mysql-5.1-opt

  Post-fix for bug#27695.

into  magare.gmz:/home/kgeorge/mysql/autopush/B31001-5.1-opt