Github user liuyu000 commented on a diff in the pull request:
https://github.com/apache/trafodion/pull/1542#discussion_r184584414
--- Diff: docs/sql_reference/src/asciidoc/_chapters/sql_statements.adoc ---
@@ -576,6 +584,59 @@ the two columns or sets of columns must have the same
characteristics (data type
the foreign key in _table_ is the column being defined; with the foreign
key clause, the foreign key is the column or set of columns specified in
the foreign key clause. for information about _ref-spec_, see references
_ref-spec_ not enforced.
+<<<
+* ENABLE ALL [UNIQUE] INDEXES
+
+** ENABLE ALL UNIQUE INDEXES
++
+enables all unique indexes on the table.
+
+** ENABLE ALL INDEXES
++
+enables all indexes (including normal indexes and unique indexes) on the
table.
--- End diff --
Thanks @DaveBirdsall, agree with you that the word "non-unique" is more
accurate. I've changed that. :)
However, I read the term "normal indexes" in:
* [Oracle SQL Reference
Manual](https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_5010.htm):
> An index is a schema object that contains an entry for each value that
appears in the indexed column(s) of the table or cluster and provides direct,
fast access to rows. Oracle Database supports several types of index:
Normal indexes. (By default, Oracle Database creates B-tree indexes.)
Bitmap indexes, which store rowids associated with a key value as a bitmap
...
> B-tree indexes
These indexes are the standard index type. They are excellent for primary
key and highly-selective indexes. Used as concatenated indexes, B-tree indexes
can retrieve data sorted by the indexed columns.
...
* [MySQL Reference
Manual](https://dev.mysql.com/doc/refman/8.0/en/optimizing-spatial-analysis.html):
> It is also possible to create normal indexes on spatial columns. In a
non-SPATIAL index, you must declare a prefix for any spatial column except for
POINT columns.
...
* [PostgreSQL
Documentation](https://www.postgresql.org/docs/9.5/static/routine-vacuuming.html):
> Second, it allows PostgreSQL to answer some queries using only the index,
without reference to the underlying table. Since PostgreSQL indexes don't
contain tuple visibility information, a normal index scan fetches the heap
tuple for each matching index entry, to check whether it should be seen by the
current transaction.
...
---
