xpressions that use functions, constant values,
operators, and so forth.

Unqualified table or view names in the SELECT statement are interpreted with
respect to the default database. A view can refer to tables or views in other
databases by qualifying the table or view name with the proper database name.

A view can be created from many kinds of SELECT statements. It can refer to
base tables or other views. It can use joins, UNION, and subqueries. The
SELECT need not even refer to any tables. The following example defines a view
that selects two columns from another table, as well as an expression
calculated from those columns:

CREATE TABLE t (qty INT, price INT);

INSERT INTO t VALUES(3, 50);

CREATE VIEW v AS SELECT qty, price, qty*price AS value FROM t;

SELECT * FROM v;
+------+-------+-------+
| qty  | price | value |
+------+-------+-------+
|    3 |    50 |   150 |
+------+-------+-------+

A view definition is subject to the following restrictions:

* The SELECT statement cannot contain a subquery in the FROM clause.
* The SELECT statement cannot refer to system or user variables.
* Within a stored program, the definition cannot refer to program parameters
or local variables.
* The SELECT statement cannot refer to prepared statement parameters.
* Any table or view referred to in the definition must exist. However, after a
view has been created, it is possible to drop a table or view that the
definition refers to. In this case, use of the view results in an error. To
check a view definition for problems of this kind, use the CHECK TABLE
statement.
* The definition cannot refer to a TEMPORARY table, and you cannot create a
TEMPORARY view.
* Any tables named in the view definition must exist at definition time.
* You cannot associate a trigger with a view.
* For valid identifiers to use as view names, see Identifier Names.

ORDER BY is allowed in a view definition, but it is ignored if you select from
a view using a statement that has its own ORDER BY.

For other options or clauses in the definition, they are added to the options
or clauses of the statement that references the view, but the effect is
undefined. For example, if a view definition includes a LIMIT clause, and you
select from the view using a statement that has its own LIMIT clause, it is
undefined which limit applies. This same principle applies to options such as
ALL, DISTINCT, or SQL_SMALL_RESULT that follow the SELECT keyword, and to
clauses such as INTO, FOR UPDATE, and LOCK IN SHARE MODE.

The PROCEDURE clause cannot be used in a view definition, and it cannot be
used if a view is referenced in the FROM clause.

If you create a view and then change the query processing environment by
changing system variables, that may affect the results that you get from the
view:

CREATE VIEW v (mycol) AS SELECT 'abc';

SET sql_mode = '';

SELECT "mycol" FROM v;
+-------+
| mycol |
+-------+
| mycol | 
+-------+

SET sql_mode = 'ANSI_QUOTES';

SELECT "mycol" FROM v;
+-------+
| mycol |
+-------+
| abc   | 
+-------+

The DEFINER and SQL SECURITY clauses determine which MariaDB account to use
when checking access privileges for the view when a statement is executed that
references the view. They were added in MySQL 5.1.2. The legal SQL SECURITY
characteristic values are DEFINER and INVOKER. These indicate that the
required privileges must be held by the user who defined or invoked the view,
respectively. The default SQL SECURITY value is DEFINER.

If a user value is given for the DEFINER clause, it should be a MariaDB
account in 'user_name'@'host_name' format (the same format used in the GRANT
statement). The user_name and host_name values both are required. The definer
can also be given as CURRENT_USER or CURRENT_USER(). The default DEFINER value
is the user who executes the CREATE VIEW statement. This is the same as
specifying DEFINER = CURRENT_USER explicitly.

If you specify the DEFINER clause, these rules determine the legal DEFINER
user values:

* If you do not have the SUPER privilege, or, from MariaDB 10.5.2, the SET
USER privilege, the only legal u