VIEWS table provides information
about views in databases. You must have the
SHOW VIEW privilege to access this
VIEWS table has these columns:
The name of the catalog to which the view belongs. This value is always
The name of the schema (database) to which the view belongs.
The name of the view.
SELECTstatement that provides the definition of the view. This column has most of what you see in the
Create Tablecolumn that
SHOW CREATE VIEWproduces. Skip the words before
SELECTand skip the words
WITH CHECK OPTION. Suppose that the original statement was:
CREATE VIEW v AS SELECT s2,s1 FROM t WHERE s1 > 5 ORDER BY s1 WITH CHECK OPTION;
Then the view definition looks like this:
SELECT s2,s1 FROM t WHERE s1 > 5 ORDER BY s1
The value of the
CHECK_OPTIONattribute. The value is one of
MySQL sets a flag, called the view updatability flag, at
CREATE VIEWtime. The flag is set to
DELETE(and similar operations) are legal for the view. Otherwise, the flag is set to
IS_UPDATABLEcolumn in the
VIEWStable displays the status of this flag.
If a view is not updatable, statements such
INSERTare illegal and are rejected. (Even if a view is updatable, it might not be possible to insert into it; for details, refer to Section 23.5.3, “Updatable and Insertable Views”.)
IS_UPDATABLEflag may be unreliable if a view depends on one or more other views, and one of these underlying views is updated. Regardless of the
IS_UPDATABLEvalue, the server keeps track of the updatability of a view and correctly rejects data change operations to views that are not updatable. If the
IS_UPDATABLEvalue for a view has become inaccurate to due to changes to underlying views, the value can be updated by deleting and re-creating the view.
The account of the user who created the view, in
SQL SECURITYcharacteristic. The value is one of
The session value of the
character_set_clientsystem variable when the view was created.
The session value of the
collation_connectionsystem variable when the view was created.
MySQL permits different
settings to tell the server the type of SQL syntax to support. For
example, you might use the
SQL mode to ensure MySQL correctly interprets the standard SQL
concatenation operator, the double bar (
your queries. If you then create a view that concatenates items,
you might worry that changing the
sql_mode setting to a value
ANSI could cause
the view to become invalid. But this is not the case. No matter
how you write out a view definition, MySQL always stores it the
same way, in a canonical form. Here is an example that shows how
the server changes a double bar concatenation operator to a
mysql> SET sql_mode = 'ANSI'; Query OK, 0 rows affected (0.00 sec) mysql> CREATE VIEW test.v AS SELECT 'a' || 'b' as col1; Query OK, 0 rows affected (0.00 sec) mysql> SELECT VIEW_DEFINITION FROM INFORMATION_SCHEMA.VIEWS WHERE TABLE_SCHEMA = 'test' AND TABLE_NAME = 'v'; +----------------------------------+ | VIEW_DEFINITION | +----------------------------------+ | select concat('a','b') AS `col1` | +----------------------------------+ 1 row in set (0.00 sec)
The advantage of storing a view definition in canonical form is
that changes made later to the value of
sql_mode do not affect the
results from the view. However, an additional consequence is that
comments prior to
stripped from the definition by the server.