returns erroneous results

Used the wrong function when fixing 30480 which lead to
no stop on end_key resulting in duplicate results from index scan

Includes test cases for the duplicates 37327 and 37329,
Duplicate rows and bad performance/High Handler_read_next values

Recommit after merge issues

added new function test_if_data_home_dir() which checks that
path does not contain mysql data home directory.
Using of 'mysql data home'/'any db name' in
DATA DIRECTORY & INDEX DIRECTORY is disallowed

Fixed a missed case in the patch for Bug#31931.
Also makes Bug#33722 a duplicate of Bug#31931.
Added tests for better coverage.
Replaced some legacy function calls.

Problem was that it did not work with corrupted/crashed tables.

Solution is to disable these commands until WL#4176 is completed

Problem was that the mix of handlers was not consistent between
CREATE and ALTER

changed so that it works like:
    - All partitions must use the same engine
      AND it must be the same as the table.
    - if one does NOT specify an engine on the table level
      then one must either NOT specify any engine on any
      partition/subpartition OR for ALL partitions/subpartitions

Note: that after a table have been created, the storage engine
is specified for all parts of the table (table/partition/subpartition)
and so when using alter, one does not need to specify it (unless one
wants to change the storage engine, then one have to specify it on the
table level)

Problem was that there are no support for symlinked files on Windows for
mysqld. So we fail when trying to create them.

Solution: Ignore the DATA/INDEX DIRECTORY clause for partitions and push
a warning. (Just like a MyISAM table)

 - dynamic configuration support
 - safe process
 - cleanups
 - create new suite for fedarated

ha_partition::update_create_info() just calls update_create_info
of a first partition, so only get the autoincrement maximum
of the first partition, so SHOW CREATE TABLE can show
small AUTO_INCREMENT parameters.
Fixed by implementing ha_partition::update_create_info() in a way
other handlers work.
HA_ARCHIVE:stats.auto_increment handling made consistent with other engines

The bug was that for ordered index scans, ha_partition::index_init() did
not put index columns into table->read_set if the underlying storage 
engine did not have HA_PARTIAL_COLUMN_READ flag. 
This was causing assertion failure when handle_ordered_index_scan() tried
to sort the records according to index order.

Fixed by making ha_partition::index_init() put index columns into table->read_set
for all ordered scans. 

  - archive test/result adjusted.
  - OPTIMIZE/ANALYZE PARTITION EXTENDED test case added.

Problems: 
  1. looking for a matching partition we miss the fact that the maximum 
     allowed value is in the PARTITION p LESS THAN MAXVALUE.
  2. one can insert maximum value if numeric maximum value is the last range.
     (should only work if LESS THAN MAXVALUE).
  3. one cannot have both numeric maximum value and MAXVALUE string as ranges 
    (the same value, but different meanings).

Fix: consider the maximum value as a supremum.

            the wrong buffer
Post-pushbuild fix
Added test case for better coverage.

It's not InnoDB specific bug.
Error is in QUEUE code, about the way we handle queue->max_at_top.
It's either '0' or '-2' and we do '^' operation to get the proper
direction. Though queue->compare() function can return '-2' as
a result of comparison sometimes. So we'll get
queue->compare() ^ queue->max_at_top == 0 (when max_at_top is -2)
and _downheap() function code will go wrong way here:
...
    if (next_index < elements &&
        (queue->compare(queue->first_cmp_arg,
                        queue->root[next_index]+offset_to_key,
                        queue->root[next_index+1]+offset_to_key) ^
         queue->max_at_top) > 0)
      next_index++;
...

Fixed by changing max_at_top to be either 1 or -1, doing
'* max_at_top' to get proper direction.

Partition handler fails updating tables with partitioning
based on timestamp field, as it calculates the timestamp field
AFTER it calculates the number of partition of a record.

Fixed by adding timestamp_field->set_time() call and disabling
such consequent calls

The new default database engine for altered table was reassigned to
the old one. That's wrong thing by itself, and (as the engine
for a subpartition gets that new value) leads to DBUG_ASSERTION
in mysql_unpack_partition()

  causes the Server to crash.

Accessing partitioned table with an apostrophe in partition options
like DATA DIRECTORY, INDEX DIRECTORY or COMMENT causes server crash.

Partition options were saved in .frm file without escaping.
When accessing such table it is not possible to properly restore
partition information.
Crashed because there was no check for partition info parser failure.

Fixed by escaping quoted text in the partition info when writing it to
the frm-file and added a check that it was able to parse the partition
info before using it 

NOTE: If the comment is written by an earlier version of the server,
the corrupted frm-file is not fixed, but left corrupted, you have to
manually drop the table and recreate it.

- Fix for
    Bug#28827 Partition test needs archive engine
    Bug#26669 Two tests on partition fail while blackhole engine is missing
  Solution: Move ARCHIVE and BLACKHOLE sub test cases to their own main test.
- The two bugs above + the fact that CSV could be also sometimes not
  available --> Move also CSV sub tests out.
- Minor cleanups
  - Replace error numbers with error names
  - fix typos, wrong comments
  - remove redundant sub test cases
  - add missing drop database
  - SET GLOBAL general_log = default is wrong, = 1 is correct

  table to partitioned

Problem:
Crashed because usage of an uninitialised mutex when auto_incrementing
  a partitioned temporary table

Fix:
Only locking (using the mutex) if not temporary table.

Refactoring code to add parameter to pack() and unpack() functions with
purpose of indicating if data should be packed in little-endian or
native order. Using new functions to always pack data for binary log
in little-endian order. The purpose of this refactoring is to allow
proper implementation of endian-agnostic pack() and unpack() functions.

Eliminating several versions of virtual pack() and unpack() functions
in favor for one single virtual function which is overridden in
subclasses.

Implementing pack() and unpack() functions for some field types that
packed data in native format regardless of the value of the
st_table_share::db_low_byte_first flag.

The field types that were packed in native format regardless are:
Field_real, Field_decimal, Field_tiny, Field_short, Field_medium,
Field_long, Field_longlong, and Field_blob.

Before the patch, row-based logging wrote the rows incorrectly on
big-endian machines where the storage engine defined its own
low_byte_first() to be FALSE on big-endian machines (the default
is TRUE), while little-endian machines wrote the fields in correct
order. The only known storage engine that does this is NDB. In effect,
this means that row-based replication from or to a big-endian
machine where the table was using NDB as storage engine failed if the
other engine was either non-NDB or on a little-endian machine.

With this patch, row-based logging is now always done in little-endian
order, while ORDER BY uses the native order if the storage engine
defines low_byte_first() to return FALSE for big-endian machines.

In addition, the max_data_length() function available in Field_blob
was generalized to the entire Field hierarchy to give the maximum
number of bytes that Field::pack() will write.

Problem: creating a partitioned table during name resolution for the 
partition function we search for column names in all parts of the
CREATE TABLE query. It is superfluous (and wrong) sometimes.

Fix: launch name resolution for the partition function against
the table we're creating.

Two cases in ha_partition::extra() was missing
(HA_EXTRA_DELETE_CANNOT_BATCH and HA_EXTRA_UPDATE_CANNOT_BATCH)
which only is currently used by NDB (which not uses ha_partition)

 when logging is enabled.
Currently the partition engine doesn't allow log tables to
be partitioned. But this was not checked and the server crashed.
Fixed by adding a check in ALTER TABLE to disable partitioning the
log tables.
While working on the cause of the problem improved the way the log
thread structures are initialized before opening the log tables.

Problem: getting an autoincrement value for a partition table in the ::info() method we call
the get_auto_increment() for all partitions. That may cause a problem for at least MyISAM
tables that rely on some table state (in this particular case table->naxt_nuber_field is 
set to 0 in the mysql_insert() and we get a crash). 
Moreover, calling get_auto_increment() is superfluous there.

Fix: use ::info(HA_STATUS_AUTO) calls to get autoincrement values for partitions instead of
get_auto_increment() ones in the ha_partition::info().

While executing ALTER TABLE ... PARTITION the server uses 
a temporary "shadow" table to create the updated table.
This shadow table then gets renamed as the original table.
The shadow table was not prefixed with the special prefix that
marks temporary tables so it was picked up by SHOW TABLE STATUS.
Fixed by isolating the code to create the shadow table name in a
separate function and prefixing the shadow table name with the
special prefix to exclude it from the list of user tables.
See bug 18775 and WL1324 for details.

the Item_neg changes INT_RESULT with DECIMAL_RESULT when
it gets this border value, what is not necessary.

- The function build_table_filename() builds up a string unconditionally 
using the forward slash as a path separator. Later, when the string is 
searched for FN_LIBCHAR by the set_up_table_before_create() function, a 
null pointer is returned that is finally used by strlen in the 
append_file_to_dir() function which causes the crash.

record in table)

key_restore function didn't work as intended in the case of
VARCHAR or BLOB fields, stored the restored key in field->ptr instead
of to_record.
That produced the wrong key so search returned wrong result

additional patch to fix SHOW CREATE behaviour

creation of the partitioned table could fail as we created Item-s for
it's list function in thd->mem_root, and then do Item->fix_fields
in the context of other table->mem_root (so that memory alloced
there was alloced in this table->mem_root). As we freed the
table->mem_root before we do thd->free_items, our Item-s had
pointers to the freed memory, that caused the crash

partitioned tables"
We have to ignore 'data directory' and 'index directory' parameters
if NO_DIR_IN_CREATE set.

Subselect's engine checks table->status field to determine if the
record was properly found when we use keyread upon the table.
Partition engine checks all the partitions for given key
before return. So if matching record was found in the first
partition and no matching records were found in the second, 
we have table->status == NOT_FOUND after the function, what
makes subselects to skip matching records.
The patch adds table->status= 0 if we actually found something.

when REORGANIZE creates new partition, no_subparts for that partition
isn't set right (call handler::set_partitions_defaults always returns 1)
Normally the number of subpartitions should be inherited from the
table.