diff --git a/doc/src/sgml/ref/create_index.sgml b/doc/src/sgml/ref/create_index.sgml
index ed4bb66aad..5e66052778 100644
--- a/doc/src/sgml/ref/create_index.sgml
+++ b/doc/src/sgml/ref/create_index.sgml
@@ -1,5 +1,5 @@
@@ -76,9 +76,10 @@ CREATE [ UNIQUE ] INDEX index_name
acc_method
- The name of the access method to be used for
- the index. The default access method is BTREE.
- PostgreSQL provides four access methods for indexes:
+ The name of the access method to be used for the index. The
+ default access method is BTREE.
+ PostgreSQL provides four access
+ methods for indexes:
@@ -225,26 +226,27 @@ ERROR: Cannot create index: 'index_name' already exists.
- In the second syntax shown above, an index is defined
- on the result of a user-specified function
- func_name applied
- to one or more columns of a single table.
- These functional indexes
- can be used to obtain fast access to data
- based on operators that would normally require some
- transformation to apply them to the base data.
+ In the second syntax shown above, an index is defined on the result
+ of a user-specified function func_name applied to one or more
+ columns of a single table. These functional
+ indexes can be used to obtain fast access to data based
+ on operators that would normally require some transformation to apply
+ them to the base data. For example, a functional index on
+ upper(col) would allow the clause
+ WHERE upper(col) = 'JIM' to use an index.
- PostgreSQL provides B-tree, R-tree, hash, and GiST access methods for
- indexes. The B-tree access method is an implementation of
- Lehman-Yao high-concurrency B-trees. The R-tree access method
- implements standard R-trees using Guttman's quadratic split algorithm.
- The hash access method is an implementation of Litwin's linear
- hashing. We mention the algorithms used solely to indicate that all
- of these access methods are fully dynamic and do not have to be
- optimized periodically (as is the case with, for example, static hash
- access methods).
+ PostgreSQL provides B-tree, R-tree, hash,
+ and GiST access methods for indexes. The B-tree access method is an
+ implementation of Lehman-Yao high-concurrency B-trees. The R-tree
+ access method implements standard R-trees using Guttman's quadratic
+ split algorithm. The hash access method is an implementation of
+ Litwin's linear hashing. We mention the algorithms used solely to
+ indicate that all of these access methods are fully dynamic and do
+ not have to be optimized periodically (as is the case with, for
+ example, static hash access methods).
@@ -338,18 +340,18 @@ ERROR: Cannot create index: 'index_name' already exists.
An operator class can be specified for each
- column of an index. The operator class identifies the operators to
- be used by the index for that column. For example, a B-tree index on
+ column of an index. The operator class identifies the operators to be
+ used by the index for that column. For example, a B-tree index on
four-byte integers would use the int4_ops class;
this operator class includes comparison functions for four-byte
- integers. In practice the default operator class for the field's
- data type is usually sufficient. The main point of having operator classes
+ integers. In practice the default operator class for the field's data
+ type is usually sufficient. The main point of having operator classes
is that for some data types, there could be more than one meaningful
- ordering. For example, we might want to sort a complex-number data type
- either by absolute value or by real part. We could do this by defining
- two operator classes for the data type and then selecting the proper
- class when making an index. There are also some operator classes with
- special purposes:
+ ordering. For example, we might want to sort a complex-number data
+ type either by absolute value or by real part. We could do this by
+ defining two operator classes for the data type and then selecting
+ the proper class when making an index. There are also some operator
+ classes with special purposes:
diff --git a/src/backend/commands/command.c b/src/backend/commands/command.c
index b230e2cd4f..c74d24cf7a 100644
--- a/src/backend/commands/command.c
+++ b/src/backend/commands/command.c
@@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
- * $Header: /cvsroot/pgsql/src/backend/commands/Attic/command.c,v 1.172 2002/04/02 08:51:50 inoue Exp $
+ * $Header: /cvsroot/pgsql/src/backend/commands/Attic/command.c,v 1.173 2002/04/11 23:20:04 momjian Exp $
*
* NOTES
* The PerformAddAttribute() code, like most of the relation
@@ -604,10 +604,10 @@ AlterTableAlterColumnDropNotNull(Oid myrelid,
elog(ERROR, "ALTER TABLE: Cannot alter system attribute \"%s\"",
colName);
- /*
+ /*
* Check that the attribute is not in a primary key
*/
-
+
/* Loop over all indices on the relation */
indexoidlist = RelationGetIndexList(rel);
@@ -986,9 +986,9 @@ AlterTableAlterColumnFlags(Oid myrelid,
elog(ERROR, "ALTER TABLE: relation \"%s\" is not a table",
RelationGetRelationName(rel));
- /*
+ /*
* we allow statistics case for system tables
- */
+ */
if (*flagType != 'S' &&
!allowSystemTableMods
&& IsSystemRelationName(RelationGetRelationName(rel)))
@@ -1911,7 +1911,7 @@ LockTableCommand(LockStmt *lockstmt)
/*
* CREATE SCHEMA
*/
-void
+void
CreateSchemaCommand(CreateSchemaStmt *stmt)
{
const char *schemaName = stmt->schemaname;
@@ -1976,13 +1976,13 @@ CreateSchemaCommand(CreateSchemaStmt *stmt)
Node *parsetree = (Node *) lfirst(parsetree_item);
List *querytree_list,
*querytree_item;
-
+
querytree_list = parse_analyze(parsetree, NULL);
-
+
foreach(querytree_item, querytree_list)
{
Query *querytree = (Query *) lfirst(querytree_item);
-
+
/* schemas should contain only utility stmts */
Assert(querytree->commandType == CMD_UTILITY);
/* do this step */