This problem was introduced in
marko.makela@oracle.com-20100514130815-ym7j7cfu88ro6km4
and is probably the reason for the following valgrind warning:

from http://bugs.mysql.com/52691 , http://bugs.mysql.com/file.php?id=16880 :

Version: '5.6.3-m5-valgrind-max-debug'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution
==14947== Thread 18:
==14947== Conditional jump or move depends on uninitialised value(s)
==14947==    at 0x4A06318: __GI_strlen (mc_replace_strmem.c:284)
==14947==    by 0x9F3D7A: fill_innodb_trx_from_cache(trx_i_s_cache_struct*, THD*, TABLE*) (i_s.cc:591)
==14947==    by 0x9F4D7D: trx_i_s_common_fill_table(THD*, TABLE_LIST*, Item*) (i_s.cc:1238)
==14947==    by 0x7689F3: get_schema_tables_result(JOIN*, enum_schema_table_state) (sql_show.cc:6745)
==14947==    by 0x715A75: JOIN::exec() (sql_select.cc:2861)
==14947==    by 0x7185BD: mysql_select(THD*, Item***, TABLE_LIST*, unsigned int, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*) (sql_select.cc:3609)
==14947==    by 0x70E823: handle_select(THD*, LEX*, select_result*, unsigned long) (sql_select.cc:319)
==14947==    by 0x6F2305: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:4557)
==14947==    by 0x6EAED4: mysql_execute_command(THD*) (sql_parse.cc:2135)
==14947==    by 0x6F44C9: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:5597)
==14947==    by 0x6E864B: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1093)
==14947==    by 0x6E785E: do_command(THD*) (sql_parse.cc:815)
==14947==    by 0x6C18DD: do_handle_one_connection(THD*) (sql_connect.cc:771)
==14947==    by 0x6C146E: handle_one_connection (sql_connect.cc:707)
==14947==    by 0x30E1807760: start_thread (pthread_create.c:301)
==14947==    by 0x35EA670F: ???
==14947==  Uninitialised value was created by a heap allocation
==14947==    at 0x4A0515D: malloc (vg_replace_malloc.c:195)
==14947==    by 0xB4B948: mem_area_alloc (mem0pool.c:385)
==14947==    by 0xB4A27C: mem_heap_create_block (mem0mem.c:333)
==14947==    by 0xB4A530: mem_heap_add_block (mem0mem.c:446)
==14947==    by 0xB0D2A4: mem_heap_alloc (mem0mem.ic:186)
==14947==    by 0xB0D9C2: ha_storage_put_memlim (ha0storage.c:118)
==14947==    by 0xA479D8: fill_trx_row (trx0i_s.c:521)
==14947==    by 0xA490E9: fetch_data_into_cache (trx0i_s.c:1319)
==14947==    by 0xA491BA: trx_i_s_possibly_fetch_data_into_cache (trx0i_s.c:1352)
==14947==    by 0x9F4CE7: trx_i_s_common_fill_table(THD*, TABLE_LIST*, Item*) (i_s.cc:1221)
==14947==    by 0x7689F3: get_schema_tables_result(JOIN*, enum_schema_table_state) (sql_show.cc:6745)
==14947==    by 0x715A75: JOIN::exec() (sql_select.cc:2861)
==14947==    by 0x7185BD: mysql_select(THD*, Item***, TABLE_LIST*, unsigned int, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*) (sql_select.cc:3609)
==14947==    by 0x70E823: handle_select(THD*, LEX*, select_result*, unsigned long) (sql_select.cc:319)
==14947==    by 0x6F2305: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:4557)
==14947==    by 0x6EAED4: mysql_execute_command(THD*) (sql_parse.cc:2135)
==14947==    by 0x6F44C9: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:5597)
==14947==    by 0x6E864B: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1093)
==14947==    by 0x6E785E: do_command(THD*) (sql_parse.cc:815)
==14947==    by 0x6C18DD: do_handle_one_connection(THD*) (sql_connect.cc:771)
==14947==    by 0x6C146E: handle_one_connection (sql_connect.cc:707)
==14947==    by 0x30E1807760: start_thread (pthread_create.c:301)
==14947==    by 0x35EA670F: ???


(gdb) bt
#0  0x0000000004a06318 in _vgrZU_libcZdsoZa___GI_strlen (str=0x3026bfa0 "insert into `blobtest` set `data`='pkefxxpkalpabzgrczlxefkreqljeqbvzrcnhvhsjsfnvxzjsltfuincffigdkmhvvcmnseluzgbtedrfmxvnrdmzesbinjgwvharkpgjplrlnqudfidbqwgbykupycxzyikzqincnsjrxgncqzlgyqwjdbjulztgsffxpjgymsnntdibvklwqylmwhsmdskmllxuwafabdjnwlyofknwuixiyrgnplmerfdewgizkdhznitesfqepsqbbwkdepkmjoseyxjofmmjaqdipwopfrwidmhqbtovdslvayxcnpewzhppeetblccppniamezibuoinvlxkafpcmozawtplfpepxwlwhymsuraezcwvjqzwogsozodlsfzjiyrcaljjhqwdrcjawvelhefzzaexvcbyorlcyupqwgjuamiqpiputtndjwcsuyzdfhuxswuowhrzdvriwrxqmcqthvzzzvivbabbnhdbtcfdtgssvmirrcddnytnctcvqplwytxxzxelldhwahalzxvgynaiwjyezhxqhlsqudngekocfvlbqprxqhyhwbaomgqiwkpfguohuvlnhtrsszgacxhhzeppyqwfwabiqzgyzkperiidyunrykopysvlcxwhrcboetjltawdjergalsfvaxncmzoznryumrjmncvhvxqvqhhbznnifkguuiffmlrbmgwtzvnuwlaguixqadkupfhasbbxnwkrvsfhrqanfmvjtzfqodtutkjlxfcogtsjywrdgmzgszjtsmimaelsveayqrwviqwwefeziuaqsqpauxpnzhaxjtkdfvvodniwezskbxfxszyniyzkzxngcfwgjlyrlskmrzxqnptwlilsxybuguafxxkvryyjrnkhhcmxuusitaflaiuxjhyfnzkahlgmaszujqmfdhyppdnpweqanmvzgjfyzjolbmprhnuuxextcaxzicfvsuochprmlf"...) at mc_replace_strmem.c:284
#1  0x00000000009f3d7b in fill_innodb_trx_from_cache (cache=0x1462440, thd=0x2a495000, table=0x2a422500) at /home/sbester/build/bzr/mysql-trunk/storage/innobase/handler/i_s.cc:591
#2  0x00000000009f4d7e in trx_i_s_common_fill_table (thd=0x2a495000, tables=0x2a4c3ec0) at /home/sbester/build/bzr/mysql-trunk/storage/innobase/handler/i_s.cc:1238
#3  0x00000000007689f4 in get_schema_tables_result (join=0x30f90c40, executed_place=PROCESSED_BY_JOIN_EXEC) at /home/sbester/build/bzr/mysql-trunk/sql/sql_show.cc:6745
#4  0x0000000000715a76 in JOIN::exec (this=0x30f90c40) at /home/sbester/build/bzr/mysql-trunk/sql/sql_select.cc:2861
#5  0x00000000007185be in mysql_select (thd=0x2a495000, rref_pointer_array=0x2a497590, tables=0x2a4c3ec0, wild_num=1, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2684619520, result=0x30319720, unit=0x2a496d28, select_lex=0x2a497378) at /home/sbester/build/bzr/mysql-trunk/sql/sql_select.cc:3609
#6  0x000000000070e824 in handle_select (thd=0x2a495000, lex=0x2a496c78, result=0x30319720, setup_tables_done_option=0) at /home/sbester/build/bzr/mysql-trunk/sql/sql_select.cc:319
#7  0x00000000006f2306 in execute_sqlcom_select (thd=0x2a495000, all_tables=0x2a4c3ec0) at /home/sbester/build/bzr/mysql-trunk/sql/sql_parse.cc:4557
#8  0x00000000006eaed5 in mysql_execute_command (thd=0x2a495000) at /home/sbester/build/bzr/mysql-trunk/sql/sql_parse.cc:2135
#9  0x00000000006f44ca in mysql_parse (thd=0x2a495000, rawbuf=0x30d80060 "select * from innodb_trx", length=24, parser_state=0x35ea5540) at /home/sbester/build/bzr/mysql-trunk/sql/sql_parse.cc:5597
#10 0x00000000006e864c in dispatch_command (command=COM_QUERY, thd=0x2a495000, packet=0x30bb4e31 "select * from innodb_trx", packet_length=24) at /home/sbester/build/bzr/mysql-trunk/sql/sql_parse.cc:1093
#11 0x00000000006e785f in do_command (thd=0x2a495000) at /home/sbester/build/bzr/mysql-trunk/sql/sql_parse.cc:815
#12 0x00000000006c18de in do_handle_one_connection (thd_arg=0x2a495000) at /home/sbester/build/bzr/mysql-trunk/sql/sql_connect.cc:771
#13 0x00000000006c146f in handle_one_connection (arg=0x2a495000) at /home/sbester/build/bzr/mysql-trunk/sql/sql_connect.cc:707
#14 0x00000030e1807761 in start_thread (arg=0x35ea6710) at pthread_create.c:301
#15 0x00000030e14e14ed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
(gdb) frame 1
#1  0x00000000009f3d7b in fill_innodb_trx_from_cache (cache=0x1462440, thd=0x2a495000, table=0x2a422500) at /home/sbester/build/bzr/mysql-trunk/storage/innobase/handler/i_s.cc:591
591                                     row->trx_query_cs);
(gdb) list
586                     if (row->trx_query) {
587                             /* store will do appropriate character set
588                             conversion check */
589                             fields[IDX_TRX_QUERY]->store(
590                                     row->trx_query, strlen(row->trx_query),
591                                     row->trx_query_cs);
592                             fields[IDX_TRX_QUERY]->set_notnull();
593                     } else {
594                             fields[IDX_TRX_QUERY]->set_null();
595                     }

According to the zlib documentation, next_in and avail_in
must be initialized before invoking inflateInit or inflateInit2.
Furthermore, the zalloc function must clear the allocated memory.

btr_copy_zblob_prefix(): Replace the d_stream parameter with buf,len
and return the copied length.

page_zip_decompress(): Invoke inflateInit2 a little later.

page_zip_zalloc(): Rename from page_zip_alloc().
Invoke mem_heap_zalloc() instead of mem_heap_alloc().

rb:619 approved by Jimmy Yang

Result File Correction For Bug Fix

Problem: a byte behind the end of input string was read
in case of a broken XML not having a quote or doublequote
character closing a string value.

Fix: changing condition not to read behind the end of input string

  @ mysql-test/r/xml.result
  @ mysql-test/t/xml.test
  Adding tests

  @ strings/xml.c
  When checking if the closing quote/doublequote was found,
  using p->cur[0] us unsafe, as p->cur can point to the byte after the value.
  Comparing p->cur to p->beg instead.

and compressed tables

buf_LRU_drop_page_hash_for_tablespace(): after releasing and
reacquiring the buffer pool mutex, do not dereference any block
descriptor pointer that is not known to be a pointer to an
uncompressed page frame (type buf_block_t; state ==
BUF_BLOCK_FILE_PAGE). Also, defer the acquisition of the block_mutex
until it is needed.

buf_page_get_gen(): Add mode == BUF_GET_IF_IN_POOL_PEEK for
buffer-fixing a block without making it young in the LRU list.

buf_page_get_gen(), buf_page_init(), buf_LRU_block_remove_hashed_page():
Set bpage->state = BUF_BLOCK_ZIP_FREE before buf_buddy_free(bpage),
so that similar race conditions might be detected a little easier.

btr_search_drop_page_hash_when_freed(): Use BUF_GET_IF_IN_POOL_PEEK
when dropping the hash indexes.

rb://528 approved by Jimmy Yang

IN OVERFLOW

Do not assign the result of the difference to a signed variable and
checking whether it is negative afterwards because this limits the max diff
to 2G on 32 bit systems. E.g. "signed = 3.5G - 1G" would be negative and the
code would assume that 3.5G < 1G. Instead compare the two variables directly
and assign to unsigned only if we know that the result of the subtraction
will be positive.

Discussed with:	Jimmy and Sunny (via IRC)

               ("-") IN DATABASE NAMES IN ALTER DATABASE.

mysqldump did not quote database name in 'ALTER DATABASE'
statements in its output. This can further cause a failure
while loading if database name contains a hyphen '-'.

This happened as, while printing the 'ALTER DATABASE'
statements, the database name was not quoted.

Fixed by quoting the database name.


client/mysqldump.c:
  Bug#11766310 : 59398: MYSQLDUMP 5.1 CAN'T HANDLE A DASH
                 ("-") IN DATABASE NAMES IN ALTER DATABASE.
  
  Modified the print statement in order to print the quoted
  database name for 'ALTER DATABASE' statements.
mysql-test/r/mysqldump.result:
  Added a test case for bug#11766310.
mysql-test/t/mysqldump.test:
  Added a test case for bug#11766310.

A separate fix for 5.1 (as 5.1 and 5.5 have seriously
differged in the related pieces of the code).
A patch for 5.5 was approved earlier.

Problem: ucs2 was correctly disallowed in "SET NAMES" only,
while mysql_real_connect() and mysql_change_user() still allowed
to use ucs2, which made server crash.

Fix: disallow ucs2 in mysql_real_connect() and mysql_change_user().

  @ sql/sql_priv.h
    - changing return type for thd_init_client_charset() to bool,
      to return errors to the caller

  @ sql/sql_var.cc
    - using new function

  @ sql/sql_connect.cc
    - thd_client_charset_init:
      in case of unsupported client character set send error and return true;
      in case of success return false
    - check_connection:
      Return error if character set initialization failed

  @ sql/sql_parse.cc
    - check charset in the very beginnig of the CMD_CHANGE_USER handling code

  @ tests/mysql_client_test.c
    - adding tests

The loop that was looping over subqueries' references to outer field used a
local boolean variable to tell whether the field was grouped or not. But the
implementor failed to reset the variable after each iteration. Thus a field
that was not directly aggregated appeared to be.

Fixed by resetting the variable upon each new iteration.

Thanks to Kristian Nielsen for finding out the root cause for the
failure, see: https://bugs.launchpad.net/maria/+bug/677407

          memory reference

There are two issues present here.
  1) There is a possibility that we test a byte beyond the
     allocated buffer

  2) We compare a byte that might never have been
     initalized to see if it's 0.

The first issue is not triggered by existing code, but an
ASSERT has been added to safe-guard against introducing
new code that triggers it.

The second issue is what triggers the Valgrind warnings
reported in the bug report. A buffer is allocated in
class String to hold the value. This buffer is populated
by the character data constituting the string, but is not
zero-terminated in most cases.  Testing if it is indeed
zero-terminated means that we check a byte that has never
been explicitly set, thus causing Valgrind to trigger.

Note that issue 2 is not a serious problem.  The variable
is read, and if it's not zero, we will set it to zero.
There are no further consequences.

Note that this patch does not fix the underlying problems
with issue 1, as it is deemed too risky to fix at this
point (as noted in the bug report).  As discussed in
the report, the c_ptr() method should probably be
replaced, but this requires a thorough analysis of the
~200 calls to the method.


sql/set_var.cc:
  These two cases have been reported to fail
  with Valgrind.

Assertion `bitmap_is_set_all(&table->s->all_set)' failed in
handler::ha_reset

This followup fixes the compilation warning
  'test_bit' may be used uninitialized in this function
introduced by the previous patch.

Assertion `bitmap_is_set_all(&table->s->all_set)' failed in
handler::ha_reset

This assertion could be triggered if two connections simultaneously
executed two bitmap test functions on the same bitmap. For example,
the assertion could be triggered if one connection executed UPDATE
while a second connection executed SELECT on the same table.

Even if bitmap test functions have read-only semantics and have
const bitmaps as parameter, several of them modified the internal
state of the bitmap. With interleaved execution of two such functions
it was possible for one function to modify the state of the same
bitmap that the other function had just modified. This lead to an
inconsistent state and could trigger the assert.

Internally the bitmap uses 32 bit words for storage. Since bitmaps
can contain any number of bits, the last word in the bitmap may
not be fully used. A 32 bit mask is maintained where a bit is set
if the corresponding bit in the last bitmap word is unused.
The problem was that several test functions applied this mask to
the last word. Sometimes the mask was negated and used to zero out
the remainder of the last word and sometimes the mask was used as-is
to fill the remainder of the last word with 1's. This meant that if
a function first used the negated mask and another function then
used the mask as-is (or vice-versa), the first function would then
get the wrong result.

This patch fixes the problem by changing the implementation of
9 bitmap functions that modified the bitmap state even if the 
bitmap was declared const. These functions now preserve the
internal state of the bitmap. This makes it possible for
two connections to concurrently execute two of these functions
on the same bitmap without issues.

The patch also removes dead testing code from my_bitmap.c.
These tests have already been moved to unittest/mysys/bitmap-t.c.
Existing test coverage of my_bitmap has been extended.

No MTR test case added as this would require adding several sync
points to the bitmap functions. The patch has been tested with
a non-deterministic test case posted on the bug report.


include/my_bit.h:
  Removed my_count_bits_ushort() which is not needed anymore.
  Added my_count_bits_uint32().
unittest/mysys/bitmap-t.c:
  Extended test coverage of my_bitmap.

attempt to create spatial index on char > 31 bytes".

Attempt to create spatial index on char field with length
greater than 31 byte led to assertion failure on server
compiled with safemutex support.

The problem occurred in mi_create() function which was called
to create a new version of table being altered. This function
failed since it detected an attempt to create a spatial key
on non-binary column and tried to return an error.
On its error path it tried to unlock THR_LOCK_myisam mutex
which has not been not locked at this point. Indeed such an
incorrect behavior was caught by safemutex wrapper and caused
assertion failure.

This patch fixes the problem by ensuring that mi_create()
doesn't releases THR_LOCK_myisam mutex on error path if it was
not acquired.

mysql-test/r/gis.result:
  Added test for bug @59888 "debug assertion when attempt to
  create spatial index on char > 31 bytes".
mysql-test/t/gis.test:
  Added test for bug @59888 "debug assertion when attempt to
  create spatial index on char > 31 bytes".
storage/myisam/mi_create.c:
  Changed mi_create() not to release THR_LOCK_myisam mutex on
  error path if it was not acquired.

rw_lock_create_func(): Initialize lock->writer_thread, so that Valgrind
will not complain even when Valgrind instrumentation is not enabled.
Flag lock->writer_thread uninitialized, so that Valgrind can complain
when it is used uninitialized.

rw_lock_set_writer_id_and_recursion_flag(): Revert the bogus Valgrind
instrumentation that was pushed in the first attempt to fix this bug.

index gives failures.

Approved by Marko

by silencing a bogus Valgrind warning:

==4392== Conditional jump or move depends on uninitialised value(s)
==4392==    at 0x5A18416: rw_lock_set_writer_id_and_recursion_flag (sync0rw.ic:283)
==4392==    by 0x5A1865C: rw_lock_x_lock_low (sync0rw.c:558)
==4392==    by 0x5A18481: rw_lock_x_lock_func (sync0rw.c:617)
==4392==    by 0x597EEE6: mtr_x_lock_func (mtr0mtr.ic:271)
==4392==    by 0x597EBBD: fsp_header_init (fsp0fsp.c:970)
==4392==    by 0x5A15E78: innobase_start_or_create_for_mysql (srv0start.c:1508)
==4392==    by 0x598B789: innobase_init(void*) (ha_innodb.cc:2282)

os_compare_and_swap_thread_id() is defined as
__sync_bool_compare_and_swap(). From the GCC doc:

`bool __sync_bool_compare_and_swap (TYPE *ptr, TYPE oldval TYPE newval, ...)'
  ...
  The "bool" version returns true if the comparison is successful and
  NEWVAL was written.

So it is not possible that the return value is uninitialized, no matter what
the arguments to os_compare_and_swap_thread_id() are. Probably Valgrind gets
confused by the implementation of the GCC internal function
__sync_bool_compare_and_swap().

InnoDB Plugin 1.0.15 has been released with MySQL 5.1.55.

> ------------------------------------------------------------
> revno: 3545
> revision-id: holyfoot@mysql.com-20110112130241-50lwmhq562otxw31
> parent: dmitry.lenev@oracle.com-20110112130830-csanweanbny2ua3n
> committer: Alexey Botchkov <holyfoot@mysql.com>
> branch nick: 51mrg
> timestamp: Wed 2011-01-12 17:02:41 +0400
> message:
>   Bug #57321 crashes and valgrind errors from spatial types 
>           Item_func_spatial_collection::fix_length_and_dec didn't call parent's method, so
>           the maybe_null was set to '0' after it. But in this case the result was
>           just NULL, that caused wrong behaviour.
>   
>   per-file comments:
>     mysql-test/r/gis.result
>   Bug #57321 crashes and valgrind errors from spatial types 
>           test result updated.
>   
>     mysql-test/t/gis.test
>   Bug #57321 crashes and valgrind errors from spatial types 
>           test case added.
>     sql/item_geofunc.h
>   Bug #57321 crashes and valgrind errors from spatial types 
>           Item_func_geometry::fix_length_and_dec() called in
>           Item_func_spatial_collection::fix_length_and_dec().

> ------------------------------------------------------------
> revno: 3537
> revision-id: davi.arnaut@oracle.com-20110107192806-rmvvxwhk10sy0219
> parent: davi.arnaut@oracle.com-20110107183336-kp8niwm2hz3wb4c3
> committer: Davi Arnaut <davi.arnaut@oracle.com>
> branch nick: mysql-5.1
> timestamp: Fri 2011-01-07 17:28:06 -0200
> message:
>   Bug#51023: Mysql server crashes on SIGHUP and destroys InnoDB files
>   
>   WIN32 compilation fixes: define ETIMEDOUT only if not available and
>   fix typos and add a missing parameter.

> ------------------------------------------------------------
> revno: 3536
> revision-id: davi.arnaut@oracle.com-20110107183336-kp8niwm2hz3wb4c3
> parent: saikumar.v@sun.com-20110106103945-rhsek9uy6f63db44
> committer: Davi Arnaut <davi.arnaut@oracle.com>
> branch nick: 51023-5.1
> timestamp: Fri 2011-01-07 16:33:36 -0200
> message:
>   Bug#51023: Mysql server crashes on SIGHUP and destroys InnoDB files
>   
>   From a user perspective, the problem is that a FLUSH LOGS or SIGHUP
>   signal could end up associating the stdout and stderr to random
>   files. In the case of this bug report, the streams would end up
>   associated to InnoDB ibd files.
>   
>   The freopen(3) function is not thread-safe on FreeBSD. What this
>   means is that if another thread calls open(2) during freopen()
>   is executing that another thread's fd returned by open(2) may get
>   re-associated with the file being passed to freopen(3). See FreeBSD
>   PR number 79887 for reference:
>   
>     http://www.freebsd.org/cgi/query-pr.cgi?pr=79887
>   
>   This problem is worked around by substituting a internal hook within
>   the FILE structure. This avoids the loss of atomicity by not having
>   the original fd closed before its duplicated.
>   
>   Patch based on the original work by Vasil Dimov.

> ------------------------------------------------------------
> revno: 3527.3.2
> revision-id: mattias.jonsson@oracle.com-20101222144517-cbv3l5jlbd0mq5s8
> parent: mattias.jonsson@oracle.com-20101222095036-2lpx0gqu4i45jtkz
> committer: Mattias Jonsson <mattias.jonsson@oracle.com>
> branch nick: b54483-51-bt_2
> timestamp: Wed 2010-12-22 15:45:17 +0100
> message:
>   Bug#54483: valgrind errors when making warnings for
>   multiline inserts into partition
>   Bug#57071: EXTRACT(WEEK from date_col) cannot be
>   allowed as partitioning function
>   
>   Renamed function according to reviewers comments.

> ------------------------------------------------------------
> revno: 3527.3.1
> revision-id: mattias.jonsson@oracle.com-20101222095036-2lpx0gqu4i45jtkz
> parent: sven.sandberg@oracle.com-20101220090735-psae11j9nwuj8vzl
> committer: Mattias Jonsson <mattias.jonsson@oracle.com>
> branch nick: b54483-51-bt_2
> timestamp: Wed 2010-12-22 10:50:36 +0100
> message:
>   Bug#54483: valgrind errors when making warnings for multiline inserts into partition
>   Bug#57071: EXTRACT(WEEK from date_col) cannot be allowed as partitioning function
>   
>   There were functions allowed as partitioning functions
>   that implicit allowed cast. That could result in unacceptable
>   behaviour.
>   
>   Solution was to check that the arguments of date and time functions
>   have allowed types (field and date/datetime/time depending on function).