Support of virtual columns added to maria engine.
mysql-test/suite/vcol/r/vcol_handler_maria.result:
Basic tests for virtual column and maria engine.
mysql-test/suite/vcol/t/vcol_handler_maria.test:
Basic tests for virtual column and maria engine.
storage/maria/ha_maria.cc:
Support of virtual columns added to maria engine.
storage/maria/ha_maria.h:
Support of virtual columns added to maria engine.
The CREATE SHOW TABLE command misplaced virtual column specifiers:
the AS clause for a virtual column was put before optional
character set attributes, not after them as required by the syntax.
Due to an invalid check for NULL of the second argument of the
Item_func_round items performed in the code of Item_func_round::real_op
the function ROUND sometimes could return wrong results.
For queries with order by clauses that employed filesort usage of
virtual column references in select lists could trigger assertion
failures. It happened because a wrong vcol_set bitmap was used for
filesort. It turned out that filesort required its own vcol_set bitmap.
Made management of the vcol_set bitmaps similar to the management
of the read_set and write_set bitmaps.
If the expression for a virtual column of table contained datetime
comparison then the execution of the second query that used this
virtual column caused a crash. It happened because the execution
of the first query that used this virtual column inserted a cached
item into the expression tree. The cached tree was allocated in
the statement memory while the expression tree was allocated in
the table memory.
Now the cached items that are inserted into expressions for virtual
columns with datetime comparisons are always allocated in the same
mem_root as the expressions for virtual columns. So now the inserted
cached items are valid for any queries that use these virtual columns.
There were two problems that caused wrong results reported with this bug.
1. In some cases stored(persistent) virtual columns were not marked
in the write_set and in the vcol_set bitmaps.
2. If the list of fields in an insert command was empty then the values of
the stored virtual columns were set to default.
To fix the first problem the function st_table::mark_virtual_columns_for_write
was modified. Now the function has a parameter that says whether the virtual
columns are to be marked for insert or for update.
To fix the second problem a special handling of empty insert lists is
added in the function fill_record().
If a virtual column was used in the ORDER BY clause of a query
and some of the columns this virtual column was based upon were
not referenced anywhere in the query then the execution of the
query could cause an assertion failure.
It happened because in this case the bitmap of the columns used
for ordering keys was not formed correctly.
There was no error thrown when creating a table with a virtual table
computed by an expression returning a row.
This caused a crash when inserting into the table.
Removed periods at the end of the error messages for virtual columns.
Adjusted output in test result files accordingly.
The functions mysql_delete and mysql_update lacked calls of
updated_virtual_fields(). This caused wrong results for
some DELETEs/UPDATEs.
Added test cases for this bug.
join cache module.
Without these calls SELECTs over tables with virtual columns
that used join cache could return wrong results. This could
be seen with the test case added into vcol_misc.test
