Use __builtin_stpcpy only if the system supports stpcpy.
This is necessary as in some cases a call to stpcpy will
be emitted if the built-in can not optimized.

Memory was allocated for storing path names inside
fn_expand(), which were not free:ed anywhere.

This patch fixes the problem by storing the path
names in statically allocated buffers instead,
which is automatically free:ed when the server
exits.

Including adding test in 5.5 requiring --big-test
flag from mysql-test-run.pl and also disabled
tests that fails.

           during EXPLAIN

Before the patch, send_eof() of some subclasses of 
select_result (e.g., select_send::send_eof()) could 
handle being called after an error had occured while others 
could not. The methods that were not well-behaved would trigger
an ASSERT on debug builds. Release builds were not affected.

Consider the following query as an example for how the ASSERT
could be triggered:

A user without execute privilege on f() does
   SELECT MAX(key1) INTO @dummy FROM t1 WHERE f() < 1;
resulting in "ERROR 42000: execute command denied to user..." 

The server would end the query by calling send_eof(). The 
fact that the error had occured would make the ASSERT trigger. 

select_dumpvar::send_eof() was the offending method in the
bug report, but the problem also applied to other 
subclasses of select_result. This patch uniforms send_eof() 
of all subclasses of select_result to handle being called 
after an error has occured. 

The test result differs on windows, since
it writes out 'localhost:<port>' instead of
only 'localhost', since it uses tcp/ip instead
of unix sockets on windows.

Fixed by replacing that column.

Also requires --big-test from some long running tests
and added a weekly run of all test requiring --big-test.

Problem:  with "make package" , many small packages are 
generated, one per CMake COMPONENT, instead of expected single
package. This is due to the new (in cmake 2.8.3) component-based 
install for archive( e.g ZIP,TGZ ) CPack generators.

See http://public.kitware.com/Bug/view.php?id=11452 for discussion.

Fix: use CPACK_MONOLITHIC_INSTALL=1 to enforce single package.
Reset this variable temporarily to 0 for  MSI creation  (MSI needs 
COMPONENTs)

structure buffer).

This is a follow-up for WL#4435. The bug actually existed not only
MYSQL_TYPE_DATETIME type. The problem was that Item_param::set_value()
was written in an assumption that it's working with expressions, i.e.
with basic data types.

There are two different quick fixes here:
  a) Change Item_param::make_field() -- remove setting of
     Send_field::length, Send_field::charsetnr, Send_field::flags and
     Send_field::type.

     That would lead to marshalling all data using basic types to the client
     (MYSQL_TYPE_LONGLONG, MYSQL_TYPE_DOUBLE, MYSQL_TYPE_STRING and
     MYSQL_TYPE_NEWDECIMAL). In particular, that means, DATETIME would be
     sent as MYSQL_TYPE_STRING, TINYINT -- as MYSQL_TYPE_LONGLONG, etc.

     That could be Ok for the client, because the client library does
     reverse conversion automatically (the client program would see DATETIME
     as MYSQL_TIME object). However, there is a problem with metadata --
     the metadata would be wrong (misleading): it would say that DATETIME is
     marshaled as MYSQL_TYPE_DATETIME, not as MYSQL_TYPE_STRING.

  b) Set Item_param::param_type properly to actual underlying field type.
     That would lead to double conversion inside the server: for example,
     MYSQL_TIME-object would be converted into STRING-object
     (in Item_param::set_value()), and then converted back to MYSQL_TIME-object
     (in Item_param::send()).

     The data however would be marshalled more properly, and also metadata would
     be correct.

This patch implements b).

There is also a possibility to avoid double conversion either by clonning
the data field, or by storing a reference to it and using it on Item::send()
time. That requires more work and might be done later.

      MySQL-shared RPM no longer provides mysql-shared

The spec file is changed to explicitly "provide" "mysql-shared"
by the "shared" sub-RPM.

Backport version info handling  (Windows-specific) from next-mr. 
Instead of adding ".res" object as linker flag, add  resource file (.rc) file to the source list.
This is more obvious and less error prone method.

Before this fix, file io for the binary log file was not accounted properly,
and showed no io at all.

This bug was due to the following issues:

1) file io for the binlog was instrumented:
- sometime as "wait/io/file/sql/binlog"
- sometime as "wait/io/file/sql/MYSQL_LOG"
leading to inconsistent event_names.

2) the binlog file itself was using an IO_CACHE,
but the IO_CACHE implementation in mysys/mf_iocache.c was
not instrumented to make performance schema calls to record file io.

3) The "wait/io/file/sql/MYSQL_LOG" instrumentation was used
for several log files, such as:
- the binary log
- the slow log
- the query log
which caused file io in these different log files to be accounted
against the same instrument.
The instrumentation needs to have a finer grain and report io
in different event_names, because each file really serves a different purpose.

With this fix:
- the IO_CACHE implementation is now instrumented
- the "wait/io/file/sql/MYSQL_LOG" instrument has been removed
- binlog io is now always instrumented with "wait/io/file/sql/binlog"
- the slow log is instrumented with a new name, "wait/io/file/sql/slow_log"
- the query log is instrumented with a new name, "wait/io/file/sql/query_log"

--with-comment correctly
      
Properly convert --with-comment
do not uppercase it, quote as it might contain spaces.

( Based on review comments)

This fix is a follow up on the fix for similar issue 56761.

When sanitizing data read from the events_waits_history_long table,
the code needs also to sanitize the schema_name / object_name / file_name pointers,
because such pointers could also hold invalid values.
Checking the string length alone was required but not sufficient.

This fix verifies that:
- the table schema and table name used in table io events
- the file name used in file io events
are valid pointers before dereferencing these pointers.

           with on duplicate key update

There was a missed corner case in the partitioning
handler, which caused the next_insert_id to be changed
in the second level handlers (i.e the hander of a partition),
which caused this debug assertion.

The solution was to always ensure that only the partitioning
level generates auto_increment values, since if it was done
within a partition, it may fail to match the partition
function.

in different default schema.

In strict mode, when data truncation or conversion happens,
THD::killed is set to THD::KILL_BAD_DATA.

This is abuse of KILL mechanism to guarantee that execution
of statement is aborted.

The stored procedures execution, on the other hand,
upon detection that a connection was killed, would
terminate immediately, without trying to restore the caller's
context, in particular, restore the caller's current schema.

The fix is, when terminating a stored procedure execution,
to only bypass cleanup if the entire connection was killed,
not in case of other forms of KILL.

Bug#57995: Compiler flag change build error on OSX 10.4: my_getncpus.c
Bug#57996: Compiler flag change build error on OSX 10.5 : bind.c
Bug#57994: Compiler flag change build error : my_redel.c
Bug#57993: Compiler flag change build error on FreeBsd 7.0 : regexec.c
Bug#57992: Compiler flag change build error on FreeBsd : mf_keycache.c
Bug#57997: Compiler flag change build error on OSX 10.6: debug_sync.cc

Fix assorted compiler generated warnings.

- added missing DBUG_RETURN
- fixed whitespace according to coding style.

This bug was introduced in this revision: 
kostja@sun.com-20100727102553-b4n2ojcyfj79l2x7
("A pre-requisite patch for the fix for Bug#52044.")

It happens because close_thread_tables() is now called in
open_and_lock_tables upon failure.  Hence, table is no longer
open when optimizer tries to do cleanup.

Fix: Make sure to do cleanup in st_select_lex_unit::prepare()
upon failure. This way, cleanup() is called before tables are
released.

ALTER TABLE RENAME, DISABLE KEYS.

The code of ALTER TABLE RENAME, DISABLE KEYS could
issue a commit while holding LOCK_open mutex.
This is a regression introduced by the fix for
Bug 54453.
This failed an assert guarding us against a potential
deadlock with connections trying to execute
FLUSH TABLES WITH READ LOCK.

The fix is to move acquisition of LOCK_open outside
the section that issues ha_autocommit_or_rollback().
LOCK_open is taken to protect against concurrent
operations with .frms and the table definition
cache, and doesn't need to cover the call to commit.

A test case added to innodb_mysql.test.

The patch is to be null-merged to 5.5, which
already has 54453 null-merged to it.