
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 user value is your own account, either
specified literally or by using CURRENT_USER. You cannot set the definer to
some other account.
* If you have the SUPER privilege, or, from MariaDB 10.5.2, the SET USER
privilege, you can specify any syntactically legal account name. If the
account does not actually exist, a warning is generated.
* If the SQL SECURITY value is DEFINER but the definer account does not exist
when the view is referenced, an error occurs.

Within a view definition, CURRENT_USER returns the view's DEFINER value by
default. For views defined with the SQL SECURITY INVOKER characteristic,
CURRENT_USER returns the account for the view's invoker. For information about
user auditing within views, see
http://dev.mysql.com/doc/refman/5.1/en/account-activity-auditing.html.

Within a stored routine that is defined with the SQL SECURITY DEFINER
characteristic, CURRENT_USER returns the routine's DEFINER value. This also
affects a view defined within such a program, if the view definition contains
a DEFINER value of CURRENT_USER.

View privileges are checked like this:

* At view definition time, the view creator must have the privileges needed to
use the top-level objects accessed by the view. For example, if the view
definition refers to table columns, the creator must have privileges for the
columns, as described previously. If the definition refers to a stored
function, only the privileges needed to invoke the function can be checked.
The privileges required when the function runs can be checked only as it
executes: For different invocations of the function, different execution paths
within the function might be taken.
* When a view is referenced, privileges for objects accessed by the view are
checked against the privileges held by the view creator or invoker, depending
on whether the SQL SECURITY characteristic is DEFINER or INVOKER, respectively.
* If reference to a view causes execution of a stored function, privilege
checking for statements executed within the function depend on whether the
function is defined with a SQL SECURITY characteristic of DEFINER or INVOKER.
If the security characteristic is DEFINER, the function runs with the
privileges of its creator. If the characteristic is INVOKER, the function runs
with the privileges determined by the view's SQL SECURITY characteristic.

Example: A view might depend on a stored function, and that function might
invoke other stored routines. For example, the following view invokes a stored
function f():

CREATE VIEW v AS SELECT * FROM t WHERE t.id = f(t.name);

Suppose that f() contains a statement such as this:

IF name IS NULL then
 CALL p1();
ELSE
 CALL p2();
END IF;
