diff --git a/doc/src/sgml/xindex.sgml b/doc/src/sgml/xindex.sgml
index d3942be6a7f..b5f4a67f525 100644
--- a/doc/src/sgml/xindex.sgml
+++ b/doc/src/sgml/xindex.sgml
@@ -1,5 +1,5 @@
@@ -107,7 +107,7 @@ SELECT oid FROM pg_am WHERE amname = 'btree';
impose a strict ordering on keys, lesser to greater. Since
Postgres allows the user to define operators,
Postgres cannot look at the name of an operator
- (eg, ">" or "<") and tell what kind of comparison it is. In fact,
+ (eg, ">" or "<") and tell what kind of comparison it is. In fact,
some access methods don't impose any ordering at all. For example,
R-trees express a rectangle-containment relationship,
whereas a hashed data structure expresses only bitwise similarity based
@@ -115,7 +115,7 @@ SELECT oid FROM pg_am WHERE amname = 'btree';
needs some consistent way of taking a qualification in your query,
looking at the operator and then deciding if a usable index exists. This
implies that Postgres needs to know, for
- example, that the "<=" and ">" operators partition a
+ example, that the "<=" and ">" operators partition a
B-tree. Postgres
uses strategies to express these relationships between
operators and the way they can be used to scan indices.
@@ -203,7 +203,7 @@ SELECT oid FROM pg_am WHERE amname = 'btree';
Strictly speaking, this routine can return a negative
- number (< 0), 0, or a non-zero positive number (> 0).
+ number (< 0), 0, or a non-zero positive number (> 0).
@@ -427,11 +427,11 @@ CREATE OPERATOR = (
FROM pg_am am, pg_opclass opcl, complex_ops_tmp c
WHERE amname = 'btree' AND
opcname = 'complex_abs_ops' AND
- c.oprname = '<';
+ c.oprname = '<';
Now do this for the other operators substituting for the "1" in the
- third line above and the "<" in the last line. Note the order:
+ third line above and the "<" in the last line. Note the order:
"less than" is 1, "less than or equal" is 2, "equal" is 3, "greater
than or equal" is 4, and "greater than" is 5.