INVOKER-security view access check wrong" into mysql-5.5 tree.

Follow-up fix: mtr died if trying to run semisync test w/o the plugin

INVOKER-security view access check wrong".

When privilege checks were done for tables used from an 
INVOKER-security view which in its turn was used from 
a DEFINER-security view connection's active security
context was incorrectly used instead of security context
with privileges of the second view's creator.

This meant that users which had enough rights to access
the DEFINER-security view and as result were supposed to 
be able successfully access it were unable to do so in 
cases when they didn't have privileges on underlying tables 
of the INVOKER-security view.

This problem was caused by the fact that for INVOKER-security
views TABLE_LIST::security_ctx member for underlying tables
were set to 0 even in cases when particular view was used from 
another DEFINER-security view. This meant that when checks of
privileges on these underlying tables was done in
setup_tables_and_check_access() active connection security 
context was used instead of context corresponding to the 
creator of caller view.

This fix addresses the problem by ensuring that underlying
tables of an INVOKER-security view inherit security context
from the view and thus correct security context is used for
privilege checks on underlying tables in cases when such view 
is used from another view with DEFINER-security.

mysql-test/r/view_grant.result:
  Added coverage for various combinations of DEFINER and
  INVOKER-security views, including test for bug #58499
  "DEFINER-security view selecting from INVOKER-security
  view access check wrong".
mysql-test/t/view_grant.test:
  Added coverage for various combinations of DEFINER and
  INVOKER-security views, including test for bug #58499
  "DEFINER-security view selecting from INVOKER-security
  view access check wrong".
sql/sql_view.cc:
  When opening a non-suid view ensure that its underlying 
  tables will get the same security context as use for
  checking privileges on the view, i.e. security context
  of view invoker. This context can be different from the
  security context which is currently active for connection 
  in cases when this non-suid view is used from a view with
  suid security. Inheriting security context in such situation
  allows correctly apply privileges of creator of suid view
  in checks for tables of non-suid view (since in this 
  situation creator/definer of suid view serves as invoker
  for non-suid view).

        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().

TIMESTAMP.

Item_cache::get_cache wasn't treating TIMESTAMP as a DATETIME value thus
returning string cache for items with TIMESTAMP type. This led to incorrect
TIMESTAMP -> INT conversion and to a wrong query result.

Fixed by using Item::is_datetime function to check for DATETIME type group.


mysql-test/r/type_timestamp.result:
  Added a test case for the bug#59330.
mysql-test/t/type_timestamp.test:
  Added a test case for the bug#59330.
sql/item.cc:
  Bug#59330: Incorrect result when comparing an aggregate function with
  TIMESTAMP.
  Item_cache::get_cache now uses is_datetime member function to detect DATETIME
  type group.

If the ::single_value_transformer() find an existing HAVING condition it used
to do the transformation:
            
  1) HAVING cond -> (HAVING Cond) AND (cond_guard (Item_ref_null_helper(...))
      
As the AND condition in 1) is Mc'Carty evaluated, the
right side of the AND cond should be executed only if the 
original 'HAVING evaluated' to true.
      
However, as we failed to set 'top_level' for the tranformed HAVING condition,
'abort_on_null' was FALSE after transformation. An
UNKNOWN having condition will then not terminate evaluation of the
transformed having condition, and we incorrectly continued
into the Item_ref_null_helper() part.

New patch, avoid global $opt_parallel
I still prefer not to print workerid when not doing parallel

tmptable needed

The function DEFAULT() works by modifying the the data buffer pointers (often
referred to as 'record' or 'table record') of its argument. This modification
is done during name resolution (fix_fields().) Unfortunately, the same
modification is done when creating a temporary table, because default values
need to propagate to the new table.

Fixed by skipping the pointer modification for fields that are arguments to
the DEFAULT function.

if max_allowed_packet >= 16M.

This bug was introduced by patch for bug#42503.

This patch restores behaviour that there was before patch
for bug#42503 was applied.

sql/net_serv.cc:
  Restored original right condition.

Local variable ds_warnings in run_query not cleared.
But when we call die() we don't have access to it.
Set global var. to point to it when allocated.

Test name spec would be cut at last /
Only do this when .test file name given, not suite.<test>

Followup: had forgotten to update mysqltest.test due to changed output - duh!

The problem from a user point of view was that on Solaris the
time related functions (e.g. NOW(), SYSDATE(), etc) would always
return a fixed time.

This bug was happening due to a logic in the time retrieving
wrapper function which would only call the time() function every
half second. This interval between calls would be calculated
using the gethrtime() and the logic relied on the fact that time
returned by it is monotonic.

Unfortunately, due to bugs in the gethrtime() implementation,
there are some cases where the time returned by it can drift
(See Solaris bug id 6600939), potentially causing the interval
calculation logic to fail.

The solution is to retrieve the correct time whenever a drift in
the time returned by gethrtime() is detected. That is, do not
use the cached time whenever the values (previous and current)
returned by gethrtime() are not monotonically increasing.

mysys/my_getsystime.c:
  Do not used the cached time if gethrtime is not monotonic.

Put descriptions of plugins into a separate file read by MTR
MTR itself has generalised code to read this and set env. variables
Removed the *SO variables, updated some tests accordingly
New commit: added optional list of plugin names for _LOAD variable
Also made changes for the new AUTH_* plugins

extended' to crash mysqld" (see http://lists.mysql.com/commits/128409).

to crash mysqld". 
      
handler::pushed_cond was not always properly reset when table objects where
recycled via the table cache.
      
handler::pushed_cond is now set to NULL in handler::ha_reset(). This should 
prevent pushed conditions from (incorrectly) re-apperaring in later queries.

Generalized fix for recursive backtick
Optional arg to eval_expr telling it not to interpret

Added a pattern match to cover combinations
Added to readme file

This patchs adds printing of a file stack (with line numbers)
It does not fix the problem of a failure in the non-first iteration of a loop

and 'THREAD_SAFE_CLIENT'.
  
As of MySQL 5.5, we no longer support non-threaded
builds.   This patch removes all references to the
obsolete THREAD and THREAD_SAFE_CLIENT preprocessor
symbols.  These were used to distinguish between
threaded and non-threaded builds.

Remove the test from defaults.experimental.

          the my.cnf, works as command
      
Different parsing mechanisms are used for command line/my.cnf 
options  and the SQL commands.  The former only accepted
numeric arguments, and regarded all numbers different from 0 
as 'true'.  Any other argument was parsed as 'false' .
      
This patch adds the words 'true' and 'on' as valid truth
values for boolean option arguments.
      
A test case is not provided, as the fix is simple and
does not warrant a separate test file (no existing
suitable test file was found)

(backported from mysql-trunk)

           OPTIMIZE TABLE

OPTIMIZE TABLE for InnoDB tables is handled as recreate + analyze.
The triggered assert checked that an error had been reported if either
recreate or analyze failed. However the assert failed to take into
account that they could have failed because OPTIMIZE TABLE had been
victim of KILL QUERY, KILL CONNECTION or server shutdown.

This patch adjusts the assert to take this possibility into account.
The problem was only noticeable on debug versions of the server.

Test case added to innodb_mysql_sync.test.

          and Order By
      
When having a UNION statement in a subquery, with no
referenced tables (or only a reference to the virtual
table 'dual'), the UNION did not allow an ORDER BY clause.
      
      i.e:
          SELECT(SELECT 1 AS a UNION 
                 SELECT 0 AS a 
                 ORDER BY a) AS b  or
          SELECT(SELECT 1 AS a FROM dual UNION 
                 SELECT 0 as a 
                 ORDER BY a) AS b
      
      
In addition, an ORDER BY / LIMIT clause was not accepted
in subqueries even for single SELECT statements with no 
referenced tables (or with 'dual' as table reference)
      
   i.e: 
      SELECT(SELECT 1 AS a ORDER BY a) AS b  or
      SELECT(SELECT 1 AS a FROM dual ORDER BY a) AS b
      
The fix was to allow an optional ORDER BY/LIMIT clause to
the grammar for these cases.
      
See also: Bug#57986

          if embedded in a SELECT
            
An ORDER BY clause was bound to the incorrect
(sub-)statement when used in a UNION context.
            
In a query like:
SELECT * FROM a UNION SELECT * FROM b ORDER BY c
the result of SELECT * FROM b is sorted, and then
combined with a.  The correct behaviour is that
the ORDER BY clause should be applied on the
final set.   Similar behaviour was seen on LIMIT
clauses as well.
            
In a UNION statement, there will be a select_lex
object for each of the two selects, and a 
select_lex_unit object that describes the UNION
itself.  Similarly, the same behaviour was also
seen on derived tables.
            
The bug was caused by using a grammar rule for
ORDER BY and LIMIT that bound these elements
to thd->lex->current_select, which points to the
last of the two selects, instead of to the 
fake_select_lex member of the master select_lex_unit
object.


sql/sql_yacc.yy:
  Need to use (opt_)union_order_or_limit to
  bind to the correct select_lex object.