Attempts to assign value to a table column from trigger by using
NEW.column_name pseudo-variable might result in garbled data.
That happened when:
  - the column had a BLOB-based type (e.g. TEXT)
    and
  - the value being assigned was retrieved from stored routine variable
    of the same type.

The problem was that BLOB values were not copied correctly in this
case. Instead of doing a copy of a real value, the value's representation
in record buffer was copied. This representation is essentially a
pointer to a buffer associated with the virtual table for routine
variables where the real value is stored. Since this buffer got
freed once trigger was left or could have changed its contents when
new value was assigned to corresponding routine variable such a shallow
copying resulted in garbled data in NEW.colum_name column.

It worked in 5.1 due to a subtle bug in create_virtual_tmp_table():
  - in 5.1 create_virtual_tmp_table() returned a table which
    had db_low_byte_first == false.
  - in 5.5 and up create_virtual_tmp_table() returns a table which
    has db_low_byte_first == true.
Actually, db_low_byte_first == false only for ISAM storage engine,
which was deprecated and removed in 5.0.

Having db_low_byte_first == false led to getting false in the
complex condition for the 2nd "if" in field_conv(), which in turn
led to copy-blob-behavior as a fall-back strategy:
  - to->table->s->db_low_byte_first was true (correct value)
  - from->table->s->db_low_byte_first was false (incorrect value)

In 5.5 and up that condition is true, which means blob-values are
not copied.

THAT CALL STORED PROCEDURES.

The bug was introduced by WL#4435. The problem was that if a stored
procedure generated a few result sets with different set of columns,
a new memory would be allocated after every EXECUTE for every
result set.

The fix is to introduce a new memory root in scope of MYSQL_STMT,
and to store result-set metadata in that memory root.

(SUBSTRING inside a stored function works too slow).

The user-visible problem was that the server started to consume memory if a
stored-routine of some sort is executed subsequently. The memory was freed
only after the corresponding connection was closed.

Technically, the problem was that the memory needed for temporary string
conversions was allocated on the connection ("persistent") memory root,
instead of statement one.

The root cause of this problem was the incorrect patch for Bug 55744.
That patch wrongly fixed a crash in prepared-statement-mode introduced by
another patch. The patch for Bug 55744 used wrong condition to check if
prepared statement mode is active (or whether the connection-scoped or
statement-scoped memory root should be used). The thing is that for
prepared statements such conversions should be done in the connection
memory root, so that that the transformations of item-tree were correctly
remembered in the PREPARE-phase.

The fix is to use proper condition to detect prepared-statement-mode and
use proper memory root.

(SUBSTRING inside a stored function works too slow).

Background:
  - THD classes derives from Query_arena, thus inherits the 'state'
    attribute and related operations (is_stmt_prepare() & co).

  - Although these operations are available in THD, they must not
    be used. THD has its own attribute to point to the active
    Query_arena -- stmt_arena.

  - So, instead of using thd->is_stmt_prepare(),
    thd->stmt_arena->is_stmt_prepare() must be used. This was the root
    cause of Bug 60025.

This patch enforces the proper way of calling those operations.
is_stmt_prepare() & co are declared as private operations
in THD (thus, they are hidden from being called on THD instance).

The patch tries to minimize changes in 5.5.

between 5.1 and 5.5, it's purpose is to set the compiler flags in a way that
does not optimize away the call stack(i.e don't use any -OX flags at all)

Automerge from mysql-5.1 into mysql-5.5.

Automerged bzr bundle from bug report:
luis.soares@oracle.com-20110505224815-6ob90n7suxsoizvs.bundle

Manual merge from mysql-5.1 into mysql-5.5.

Conflicts
=========
Text conflict in mysql-test/suite/rpl/t/rpl_row_until.test
Text conflict in sql/handler.h
Text conflict in storage/archive/ha_archive.cc

            
Fix for all "postion" in Oracle files (s/postion/position). 
Updated the copyright notices where needed.

Automerging cset into latest mysql-5.5.

WORK WITH --START-POSITION
      
If setting --start-position to start after the FD event, mysqlbinlog
will output an error stating that it has not found an FD event.
However, its not that mysqlbinlog does not find it but rather that it
does not processes it in the regular way (i.e., it does not print it).
Given that one is using --base64-output=DECODE-ROWS then not printing
it is actually fine.
      
To fix this, we make mysqlbinlog not to complain when it has not
printed the FD event, is outputing in base64, but is decoding the
rows.

patch so that it can later be compared with patchs with expanded symlinks 

The new --secure-file-priv checks dereference any symlinks in the paths and compare the 
resolved paths.
Thus the 5.0 test suite must do as the 5.1 and up and avoid using symlinks.

The query was re-written *after* we had tagged it with NON_AGG_FIELD_USED.
Remove the flag before continuing.


mysql-test/r/explain.result:
  Update test case for Bug#48295.
mysql-test/r/subselect.result:
  New test case.
mysql-test/t/explain.test:
  Update test case for Bug#48295.
mysql-test/t/subselect.test:
  New test case.
sql/item.cc:
  Use accessor functions for non_agg_field_used/agg_func_used.
sql/item_subselect.cc:
  Remove non_agg_field_used when we rewrite query '1 < some (...)' => '1 < max(...)'
sql/item_sum.cc:
  Use accessor functions for non_agg_field_used/agg_func_used.
sql/mysql_priv.h:
  Remove unused #defines.
sql/sql_lex.cc:
  Initialize new member variables.
sql/sql_lex.h:
  Replace full_group_by_flag with two boolean flags,
  and itroduce accessors for manipulating them.
sql/sql_select.cc:
  Use accessor functions for non_agg_field_used/agg_func_used.

There are a couple of valgrind warnings in 5.5 codebase, that
do not exist in 5.6. The root cause was found and fixed in 5.6
codebase before (BUG#11763880 and BUG#11763879), but the patches
were only pushed to 5.6.

To fix it in 5.5, we cherrypicked the csets from 5.6 and merged 
them in 5.5.

zhenxing.he@sun.com-20101117085902-n9gfvlkmm44t38y0
  
This takes care of valgrind warnings in 5.5 that exhibit
the same trace as in BUG#11763879 (BUG#56649).

zhenxing.he@sun.com-20101202073812-iel8lvhmulyagtsv

This takes care of valgrind warnings in 5.5 that exhibit
the same trace as in BUG#11763880 (BUG#56650).

The problem was that wrong structure of mysql.event was not detected and
the server continued to use wrongly-structured data.

The fix is to check the structure of mysql.event after opening before
any use. That makes operations with events more strict -- some operations
that might work before throw errors now. That seems to be Ok.

Another side-effect of the patch is that if mysql.event is corrupted,
unrelated DROP DATABASE statements issue an SQL warning about inability
to open mysql.event table. 

The XPATH implementation was not handling correctly the XPATH 
production #19 
(http://www.w3.org/TR/1999/REC-xpath-19991116/#node-sets),
namely

PathExpr ::= | FilterExpr '/' RelativeLocationPath
                    | FilterExpr '//' RelativeLocationPath

It was lacking context for the RelativeLocationPath and it was just 
ignoring the second slash instead of treating it as a different axis 
specifier.
Fixed the above two problems and added a test case.