Problem was that SQL level tried to read a record with rnd_pos()
that was already deleted by the same statement.
In the case where the page for the record had been deleted, this
caused an assert.
Fixed by extending the assert to also handle empty pages and
return HA_ERR_RECORD_DELETED for reads to deleted pages.

MDEV-17022: check if mtr --mem location is writeable

The common case for this function is that both types are the same.

The Item_result defination from include/mysql.h.pp is the following enum
   enum Item_result
   {
     STRING_RESULT=0, REAL_RESULT, INT_RESULT, ROW_RESULT, DECIMAL_RESULT,
     TIME_RESULT
   };

The compilers aren't quite smart enough to optimize to this shortcut so
this makes it quicker.

Before the change:

0000000000012730 <item_cmp_type(Item_result, Item_result)>:
   12730:       89 f0                   mov    %esi,%eax
   12732:       09 f8                   or     %edi,%eax
   12734:       74 4c                   je     12782 <item_cmp_type(Item_result, Item_result)+0x52>
   12736:       83 ff 02                cmp    $0x2,%edi
   12739:       75 0a                   jne    12745 <item_cmp_type(Item_result, Item_result)+0x15>
   1273b:       b8 02 00 00 00          mov    $0x2,%eax
   12740:       83 fe 02                cmp    $0x2,%esi
   12743:       74 3c                   je     12781 <item_cmp_type(Item_result, Item_result)+0x51>
   12745:       83 ff 03                cmp    $0x3,%edi
   12748:       b8 03 00 00 00          mov    $0x3,%eax
   1274d:       74 32                   je     12781 <item_cmp_type(Item_result, Item_result)+0x51>
   1274f:       83 fe 03                cmp    $0x3,%esi
   12752:       74 2d                   je     12781 <item_cmp_type(Item_result, Item_result)+0x51>
   12754:       83 ff 05                cmp    $0x5,%edi
   12757:       b8 05 00 00 00          mov    $0x5,%eax
   1275c:       74 23                   je     12781 <item_cmp_type(Item_result, Item_result)+0x51>
   1275e:       83 fe 05                cmp    $0x5,%esi
   12761:       74 1e                   je     12781 <item_cmp_type(Item_result, Item_result)+0x51>
   12763:       83 ff 04                cmp    $0x4,%edi
   12766:       74 05                   je     1276d <item_cmp_type(Item_result, Item_result)+0x3d>
   12768:       83 ff 02                cmp    $0x2,%edi
   1276b:       75 0f                   jne    1277c <item_cmp_type(Item_result, Item_result)+0x4c>
   1276d:       b8 04 00 00 00          mov    $0x4,%eax
   12772:       83 fe 02                cmp    $0x2,%esi
   12775:       74 0a                   je     12781 <item_cmp_type(Item_result, Item_result)+0x51>
   12777:       83 fe 04                cmp    $0x4,%esi
   1277a:       74 05                   je     12781 <item_cmp_type(Item_result, Item_result)+0x51>
   1277c:       b8 01 00 00 00          mov    $0x1,%eax
   12781:       c3                      retq
   12782:       31 c0                   xor    %eax,%eax
   12784:       c3                      retq

After, noting the short cut and the beginning of the function:

0000000000012730 <item_cmp_type(Item_result, Item_result)>:
   12730:       39 f7                   cmp    %esi,%edi
   12732:       75 03                   jne    12737 <item_cmp_type(Item_result, Item_result)+0x7>
   12734:       89 f8                   mov    %edi,%eax
   12736:       c3                      retq
   12737:       83 ff 03                cmp    $0x3,%edi
   1273a:       b8 03 00 00 00          mov    $0x3,%eax
   1273f:       74 32                   je     12773 <item_cmp_type(Item_result, Item_result)+0x43>
   12741:       83 fe 03                cmp    $0x3,%esi
   12744:       74 2d                   je     12773 <item_cmp_type(Item_result, Item_result)+0x43>
   12746:       83 ff 05                cmp    $0x5,%edi
   12749:       b8 05 00 00 00          mov    $0x5,%eax
   1274e:       74 23                   je     12773 <item_cmp_type(Item_result, Item_result)+0x43>
   12750:       83 fe 05                cmp    $0x5,%esi
   12753:       74 1e                   je     12773 <item_cmp_type(Item_result, Item_result)+0x43>
   12755:       83 ff 04                cmp    $0x4,%edi
   12758:       74 05                   je     1275f <item_cmp_type(Item_result, Item_result)+0x2f>
   1275a:       83 ff 02                cmp    $0x2,%edi
   1275d:       75 0f                   jne    1276e <item_cmp_type(Item_result, Item_result)+0x3e>
   1275f:       b8 04 00 00 00          mov    $0x4,%eax
   12764:       83 fe 02                cmp    $0x2,%esi
   12767:       74 0a                   je     12773 <item_cmp_type(Item_result, Item_result)+0x43>
   12769:       83 fe 04                cmp    $0x4,%esi
   1276c:       74 05                   je     12773 <item_cmp_type(Item_result, Item_result)+0x43>
   1276e:       b8 01 00 00 00          mov    $0x1,%eax
   12773:       c3                      retq
Signed-off-by: Daniel Black <daniel@linux.vnet.ibm.com>

MDEV-15475: Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' failed on EXPLAIN EXTENDED with constant table and view

Print constant ISNULL value independent.
Fix of printing of view FRM and CREATE VIEW output

Use real DACL instead of NULL DACL.
Grant Everyone just read/write access to pipe
(instead of all access like previously with NULL ACL)

truncate incorrect values in convert_period_to_month() so that
PERIOD_DIFF never returns a value outside of 2^23 range.

And, for safety, increase buffer sizes for int10_to_str
to be sufficienly big for any int10_to_str result.

not empty

We should swap the list only when list is not empty.

with spatial index

So the issue is since it is spatial index , at the time of searching index
for key (Rows_log_event::find_row) we use wrong field image we use
Field::itRAW while we should be using Field::itMBR

No commit message

We do not accept:
1. We did not have this problem (fixed earlier and better)
 d982e717 Bug#27510150: MYSQLDUMP FAILS FOR SPECIFIC --WHERE CLAUSES
2. We do not have such options (an DBUG_ASSERT put just in case)
 bbc2e37f Bug#27759871: BACKRONYM ISSUE IS STILL IN MYSQL 5.7
3. Serg fixed it in other way in this release:
 e48d775c Bug#27980823: HEAP OVERFLOW VULNERABILITIES IN MYSQL CLIENT LIBRARY

In this case we are setting the field Item_func_eq::in_eqaulity_no for the semi-join equalities.
This helps us to remove these equalites as the inner tables are not available during parent select execution
while the outer tables are not available during materialization phase.
We only have it set for the equalites for the fields involved with the IN subquery
and reset it for the equalities which do not belong to the IN subquery.

For example in case of nested IN subqueries:

    SELECT t1.a FROM t1 WHERE t1.a IN
      (SELECT t2.a FROM t2 where t2.b IN
          (select t3.b from t3 where t3.c=27 ))

there are two equalites involving the fields of the IN subquery

1) t2.b = t3.b :  the field Item_func_eq::in_eqaulity_no is set when we merge the grandchild select into the child select
2) t1.a = t2.a :  the field Item_func_eq::in_eqaulity_no is set when we merge the child select into the parent select

But when we perform case 2) we should ensure that we reset the equalities in the child's WHERE clause.

MDEV-16751: Server crashes in st_join_table::cleanup or TABLE_LIST::is_with_table_recursive_reference
            with join_cache_level>2

During muliple equality propagation for a query in which we have an IN subquery, the items in the select list of the
subquery may not be part of the multiple equality because there might be another occurence of the same field in the
where clause of the subquery.
So we keyuse_is_valid_for_access_in_chosen_plan function which expects the items in the select list of the subquery to
be same to the ones in the multiple equality (through these multiple equalities we create keyuse array).
The solution would be that we expect the same field not the same Item because when we have SEMI JOIN MATERIALIZATION SCAN,
we use copy back technique to copies back the materialised table fields to the original fields of the base tables.

This patch fixes another problem introduced by the patch for mdev-4817.
The latter changed Item_cond::fix_fields() in such a way that it could
call the virtual method is_expensive(). With the first its call
the method saves the result in Item::is_expensive_cache. For all next
calls the method returns the result from this cache. So if the item
once was determined as expensive the method always returns true.
For subqueries it's not good, because non-optimized subqueries always
is considered as expensive.
It means that the cache should be invalidated after the call of
optimize_constant_subqueries().

Due to a legacy bug in the code of make_join_statistics() detecting
so-called constant tables could miss some of them in rare queries
that used RIGHT JOIN. As a result these queries had execution plans
different from the execution plans of the equivalent queries with
LEFT JOIN.
Besides starting from 10.2 this could trigger an assertion failure.

Closes #551

fix_semijoin_strategies_for_picked_join_order() should set
join->sjm_lookup_tables to be a bitmap of tables inside
SJ-Materialization-Lookup nests.

In this issue we are using derived_with_keys optimization and we are using these keys to do a hash join which is incorrect.
We cannot create keys for dervied tables whose keyparts have types are of BLOB or TEXT type. TEXT or BLOB  columns can only be
indexed over a specified length.

When the definition of the index used for hash join was created
in create_hj_key_for_table() it could cause memory overwrite
due to a bug that led to an underestimation of the number of
the index component.

For the purpose of reporting an error to error log, shutdown thread was
attempting to access current_thd->variables.lc_messages->errmsgs->errmsgs.
Whereas current_thd was NULL.

We should log errors according to global lc_messages setting instead of
session setting.

MDEV-16512 Server crashes in find_field_in_table_ref on 2nd
execution of SP referring to non-existing field

Problem was in the natural join code that it changed TABLE_LIST and
Item_fields but didn't restore changed things if things goes wrong
and was not able to re-execute after failure.
Some of the problems could have been avoided if we would have run
fix_fields before doing natural join transformations.

Fixed by marking functions complete AFTER they had executed, instead at
start.
I had also to change some tests that checked if Item_fields are usable.

This doesn't fix all known problems, but at least avoids some crashes.
What should be done in the near future is to mark the statement in the SP
as 'not re-executable' and force a reparse of it on next execution.

Reviewer: Sergei Petrunia <psergey@askmonty.org>

This reverts commit d39629f0.

Because running mtr for many hours with no output whatsoever
is not really what we should do.

And in 5.5 `make test` just works anyway, nothing to fix here.

MDEV-16534 PPC64: Unexpected error with a negative value into auto-increment columns in HEAP, MyISAM, ARIA

(cherry picked from commit b5b986b2cbd9a7848dc3f48e5c42b6d4e1e5fb22)

Added unregistering writers in case of log error.
Added more debugging control about adding/removing writers to the buffers.

           SELECT .. LIMIT 0 (new variant)

This is another attempt to fix the problem of mdev-14515.

update table->pos_in_table_list during prepare,
just like it's done in normal execution.

otherwise it'll be a dangling pointer

adjust tests

rewrite tautological engine descriptions

The order of outputting stored procedures is important. Stored
procedures must be available on view creation, for views which make use
of them. Make sure to print them before outputting tables.

Undo the revert that happened by mystake in commit 7fca4b50.

GCC-8 introduced multiple warnings and increased the level of
strictness.

* -Wshadow will warn if a local variable shadows a typedef.
* GCC will also warn when memsetting a non-trivial type.
  In this case a non-trivial type can not have a custom constructor.
  For all intents and purposes, the class is trivially-copyable.
* GCC will also warn if you use too many paranthesses which are not
necessary