MySQL 5.6 Reference Manual Including MySQL NDB Cluster 7.3-7.4 Reference Guide
SHOW CREATE VIEW view_name
This statement shows the CREATE
VIEW
statement that creates the named 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: utf8
collation_connection: utf8_general_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.
View information is also available from the
INFORMATION_SCHEMA
VIEWS
table. See
Section 21.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
does 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.