Spec-Zone .ru
спецификации, руководства, описания, API
|
SHOW CREATE VIEW view_name
This statement shows a CREATE VIEW
statement that creates the given view.
mysql> SHOW CREATE VIEW v\G
*************************** 1. row *************************** View: v Create View: CREATE ALGORITHM=UNDEFINED DEFINER=`bob`@`localhost` SQL SECURITY DEFINER VIEW `v` AS select 1 AS `a`,2 AS `b`character_set_client: latin1collation_connection: latin1_swedish_ci
character_set_client
is the session value of the character_set_client
system variable when the view was created. collation_connection
is the session value of the collation_connection
system variable when the view was created.
Use of SHOW CREATE VIEW
requires the SHOW VIEW
privilege and the SELECT
privilege for the view in question.
You can also obtain information about view objects from INFORMATION_SCHEMA
, which
contains a VIEWS
table.
See Section 20.29, "The INFORMATION_SCHEMA
VIEWS
Table".
MySQL lets you use different sql_mode
settings to tell the server the type of SQL syntax to support. For
example, you might use the ANSI
SQL mode to ensure MySQL correctly interprets the standard SQL concatenation operator, the double bar (||
), in your queries. If you then create a view that concatenates items, you
might worry that changing the sql_mode
setting to a value different from 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 CONCAT()
function:
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.01 sec)mysql>SHOW CREATE VIEW test.v\G
*************************** 1. row *************************** View: v Create View: CREATE VIEW "v" AS 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
will not affect the results from the view. However an additional consequence is that comments prior to SELECT
are stripped from the definition by the server.