Added function last_value() which returns the last value but evalutes all arguments as a side effect.
Original patch by Eric Herman

client/mysql.cc:
  Added LAST_VALUE
mysql-test/r/last_value.result:
  Testing of LAST_VALUE
mysql-test/t/last_value.test:
  Testing of LAST_VALUE
sql/item_func.cc:
  Added LAST_VALUE()
sql/item_func.h:
  Added LAST_VALUE()
sql/lex.h:
  Added LAST_VALUE()
sql/sql_yacc.yy:
  Added LAST_VALUE()

MDEV-414 Depending on indexes or execution plans, a warning on incorrect or out of range values in WHERE condition is sometimes produced and sometimes not

use the same method that disables warnings in all relevant places, remove redundant function

When we append data to the binlog file, we use fdatasync() to ensure
the data gets to disk so that crash recovery can work.

Unfortunately there seems to be a bug in ext3/ext4 on linux, so that
fdatasync() does not correctly sync all data when the size of a file
is increased. This causes crash recovery to not work correctly (it
loses transactions from the binlog).

As a work-around, use fsync() for the binlog, not fdatasync(). Since
we are increasing the file size, (correct) fdatasync() will most
likely not be faster than fsync() on any file system, and fsync()
does work correctly on ext3/ext4. This avoids the need to try to
detect if we are running on buggy ext3/ext4.

store the precision in uint, not uint8

MDEV-438 Microseconds: Precision is ignored in CURRENT_TIMESTAMP(N) when it is given as a default column value

The syntax for specifying precision in the DEFAULT clause is unintentional and unsupported.
Don't allow it anymore.

1. Field_newdate::get_date should refuse to return a date with zeros when
   TIME_NO_ZERO_IN_DATE is set, not when TIME_FUZZY_DATE is unset
2. Item_func_to_days and Item_date_add_interval can only work with valid dates,
   no zeros allowed.

fix Item_func_add_time::get_date() to generate valid dates.
Move the validity check inside get_date_from_daynr()
instead of relying on callers
(5 that had it, and 2 that did not, but should've)

Split ER_NO_SUCH_TABLE into ER_NO_SUCH_TABLE and ER_NO_SUCH_TABLE_IN_ENGINE to be able to distingus if a .frm file is missing or if the table is missing in the engine.


sql/handler.cc:
  Added ER_NO_SUCH_TABLE_IN_ENGINE
sql/rpl_record.cc:
  Fixed wrong printf
sql/share/errmsg-utf8.txt:
  Added ER_NO_SUCH_TABLE_IN_ENGINE
sql/sp.cc:
  Added ER_NO_SUCH_TABLE_IN_ENGINE
sql/sp_head.cc:
  Added ER_NO_SUCH_TABLE_IN_ENGINE
sql/sql_admin.cc:
  Added ER_NO_SUCH_TABLE_IN_ENGINE
sql/sql_base.cc:
  Added ER_NO_SUCH_TABLE_IN_ENGINE
sql/sql_show.cc:
  Added ER_NO_SUCH_TABLE_IN_ENGINE
sql/table.cc:
  Fixed typo

MDEV-405: Server crashes in test_if_skip_sort_order on EXPLAIN with GROUP BY and HAVING in EXISTS subquery
- Testcase

- Don't do early cleanup of uncorrelated subqueries if we're running an EXPLAIN.

        the fill_help_table-5.5.sql file was copied into mariadb.

per-file comments:
  scripts/fill_help_tables.sql
        MDEV-471 update help tables.

storage engine in HA_MRR_NO_ASSOCIATION mode.
(there is no testcase because we don't ship any such engines currently)

force -fno-strict-aliasing for oqgraph

The problem was that was_null and null_value variables was reset in each reexecution of IN subquery, but engine rerun only for non-constant subqueries.

Fixed checking constant in Item_equal sort.
Fix constant reporting in Item_subselect.