Oracle 5.0 Reference Manual page 1736

| fk2 | BASE TABLE | InnoDB |
| fk | BASE TABLE | InnoDB |
+------------+------------+--------+
17 rows in set (0.01 sec)
Explanation: The statement requests a list of all the tables in database db5, in reverse alphabetic
order, showing just three pieces of information: the name of the table, its type, and its storage engine.
The definition for character columns (for example, TABLES.TABLE_NAME) is generally
CHARACTER SET utf8
set (utf8_general_ci) for all searches, sorts, comparisons, and other string operations on such
columns. Values such as table names in
not identifiers, and are not compared using the identifier rules described in
Case Sensitivity". If the result of a string operation on an
from expectations, a workaround is to use an explicit
(Section 10.1.7.2, "Using
[890] function. For example, in a
LOWER()
WHERE TABLE_NAME COLLATE utf8_bin = 'City'
WHERE TABLE_NAME COLLATE utf8_general_ci = 'city'
WHERE UPPER(TABLE_NAME) = 'CITY'
WHERE LOWER(TABLE_NAME) = 'city'
Each MySQL user has the right to access these tables, but can see only the rows in the tables that
correspond to objects for which the user has the proper access privileges. In some cases (for example,
the
ROUTINE_DEFINITION
insufficient privileges will see NULL.
The
SELECT ... FROM INFORMATION_SCHEMA
to provide access to the information provided by the various
(SHOW
DATABASES, SHOW
SHOW:
• It conforms to Codd's rules. That is, all access is done on tables.
• Nobody needs to learn a new statement syntax. Because they already know how
they only need to learn the object names.
• The implementor need not worry about adding keywords.
• There are millions of possible output variations, instead of just one. This provides more flexibility for
applications that have varying requirements about what metadata they need.
• Migration is easier because every other DBMS does it this way.
However, because
SHOW
advantages of conventional syntax are not a sufficient reason to eliminate SHOW. In fact, along with
the implementation of INFORMATION_SCHEMA, there are enhancements to
described in Section 19.18, "Extensions to
There is no difference between the privileges required for
select information from INFORMATION_SCHEMA. In either case, you have to have some privilege on an
object in order to see information about it.
The implementation for the
SQL:2003 standard Part 11 Schemata. Our intent is approximate compliance with SQL:2003 core
feature F021 Basic information schema.
Users of SQL Server 2000 (which also follows the standard) may notice a strong similarity.
However, MySQL has omitted many columns that are not relevant for our implementation,
and added columns that are MySQL-specific. One such column is the
INFORMATION_SCHEMA.TABLES
where is at least 64. MySQL uses the default collation for this character
N
INFORMATION_SCHEMA
in SQL Statements"). You can also use the
COLLATE
WHERE
column in the
INFORMATION_SCHEMA.ROUTINES
TABLES, and so forth). Using
is popular and because it might be confusing were it to disappear, the
SHOW
INFORMATION_SCHEMA
table.
1716
columns are treated as strings,
INFORMATION_SCHEMA
clause to force a suitable collation
COLLATE
clause, you might use:
statement is intended as a more consistent way
statements that MySQL supports
SHOW
has these advantages, compared to
SELECT
Statements".
statements and those required to
SHOW
table structures in MySQL follows the ANSI/ISO
ENGINE
VARCHAR(N)
Section 9.2.2, "Identifier
column differs
[895] or
UPPER()
table), users who have
works,
SELECT
as well. These are
SHOW
column in the