
the same statement is also adding other columns if ALGORITHM is not set to
COPY. See MDEV-17468 for more information.
It also does not support altering an existing column into a VIRTUAL generated
column.
It supports using generated columns to partition tables.
It does not support using the versioning clauses with generated columns.

* The SHOW CREATE TABLE statement supports generated columns.

* The DESCRIBE statement can be used to check whether a table has generated
columns.
You can tell which columns are generated by looking for the ones where the
Extra column is set to either VIRTUAL or PERSISTENT. For example:

DESCRIBE table1;
+-------+-------------+------+-----+---------+------------+
| Field | Type        | Null | Key | Default | Extra      |
+-------+-------------+------+-----+---------+------------+
| a     | int(11)     | NO   |     | NULL    |            |
| b     | varchar(32) | YES  |     | NULL    |            |
| c     | int(11)     | YES  |     | NULL    | VIRTUAL    |
| d     | varchar(5)  | YES  |     | NULL    | PERSISTENT |
+-------+-------------+------+-----+---------+------------+

* Generated columns can be properly referenced in the NEW and OLD rows in
triggers.

* Stored procedures support generated columns.

* The HANDLER statement supports generated columns.

Expression Support
------------------

* Most legal, deterministic expressions which can be calculated are supported
in expressions for generated columns.

* Most built-in functions are supported in expressions for generated columns.
However, some built-in functions can't be supported for technical reasons. For
example,  If you try to use an unsupported function in an expression, an error
is generated similar to the following:

ERROR 1901 (HY000): Function or expression 'dayname()' cannot be used in the
GENERATED ALWAYS AS clause of `v`

* Subqueries are not supported in expressions for generated columns because
the underlying data can change.

* Using anything that depends on data outside the row is not supported in
expressions for generated columns.

* Stored functions are not supported in expressions for generated columns. See
MDEV-17587 for more information.

* Non-deterministic built-in functions are supported in expressions for not
indexed VIRTUAL generated columns.

* Non-deterministic built-in functions are not supported in expressions for
PERSISTENT or indexed VIRTUAL generated columns.

* User-defined functions (UDFs) are supported in expressions for generated
columns.
However, MariaDB can't check whether a UDF is deterministic, so it is up to
the user to be sure that they do not use non-deterministic UDFs with VIRTUAL
generated columns.

* Defining a generated column based on other generated columns defined before
it in the table definition is supported. For example:

CREATE TABLE t1 (a int as (1), b int as (a));

* However, defining a generated column based on other generated columns
defined after in the table definition is not supported in expressions for
generation columns because generated columns are calculated in the order they
are defined.

* Using an expression that exceeds 255 characters in length is supported in
expressions for generated columns. The new limit for the entire table
definition, including all expressions for generated columns, is 65,535 bytes.

* Using constant expressions is supported in expressions for generated
columns. For example:

CREATE TABLE t1 (a int as (1));

Making Stored Values Consistent
-------------------------------

When a generated column is PERSISTENT or indexed, the value of the expression
needs to be consistent regardless of the SQL Mode flags in the current
session. If it is not, then the table will be seen as corrupted when the value
that should actually be returned by the computed expression and the value that
was previously stored and/or indexed using a different sql_mode setting
disagree.

There are currently two affected classes of inconsistencies: character padding
and unsigned subtraction:

* For a VARCHAR or TEXT generated column the length of the value returned can
vary depending on the PAD_CHAR_TO_FULL_LENGTH sql_mode flag.  To make the
value consistent, create the generated column using an RTRIM() or RPAD()
function.  Alternately, create the generated column as a CHAR column so that
its data is always fully padded.

* If a SIGNED generated column is based on the subtraction of an UNSIGNED
value, the resulting value can vary depending on how large the value is and
the NO_UNSIGNED_SUBTRACTION sql_mode flag.  To make the value consistent, use
CAST() to ensure that each UNSIGNED operand is SIGNED before the subtraction.

MariaDB starting with 10.5
--------------------------
Beginning in MariaDB 10.5, there is a fatal error generated when trying to
create a generated column whose value can change depending on the SQL Mode
when its data is PERSISTENT or indexed.

For an existing generated column that has a potentially inconsistent value, a
warning about a bad expression is generated the first time it is used (if
warnings are enabled).

Beginning in MariaDB 10.4.8, MariaDB 10.3.18, and MariaDB 10.2.27 a
potentially inconsistent generated column outputs a warning when created or
first used (without restricting their creation).

Here is an example of two tables that would be rejected in MariaDB 10.5 and
warned about in the other listed versions:

CREATE TABLE bad_pad (
 txt CHAR(5),