L or PERSISTENT generated columns cannot be explicitly set to
any other values than NULL or DEFAULT. If a generated column is explicitly set
to any other value, then the outcome depends on whether strict mode is enabled
in sql_mode. If it is not enabled, then a warning will be raised and the
default generated value will be used instead. If it is enabled, then an error
will be raised instead.

* The CREATE TABLE statement has limited support for generated columns.
It supports defining generated columns in a new table.
It supports using generated columns to partition tables.
It does not support using the versioning clauses with generated columns.

* The ALTER TABLE statement has limited support for generated columns.
It supports the MODIFY and CHANGE clauses for PERSISTENT generated columns.
It does not support the MODIFY clause for VIRTUAL generated columns if
ALGORITHM is not set to COPY. See MDEV-15476 for more information.
It does not support the  CHANGE clause for VIRTUAL generated columns if
ALGORITHM is not set to COPY. See MDEV-17035 for more information.
It does not support altering a table if ALGORITHM is not set to COPY if the
table has a VIRTUAL generated column that is indexed. See MDEV-14046 for more
information.
It does not support adding a VIRTUAL generated column with the ADD clause if
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 taÂ