Spell checking and markup refinement

src/backend/access/gist/gist.c

@@ -227,7 +227,7 @@ gistbuildempty(PG_FUNCTION_ARGS)
 {
 	ereport(ERROR,
 			(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
-			 errmsg("unlogged GIST indexes are not supported")));
+			 errmsg("unlogged GiST indexes are not supported")));
 
 	PG_RETURN_VOID();
 }
@@ -1405,7 +1405,7 @@ initGISTstate(GISTSTATE *giststate, Relation index)
 		 * functions don't care about collation, so we just do it
 		 * unconditionally.  (We could alternatively call get_typcollation,
 		 * but that seems like expensive overkill --- there aren't going to be
-		 * any cases where a GIST storage type has a nondefault collation.)
+		 * any cases where a GiST storage type has a nondefault collation.)
 		 */
 		if (OidIsValid(index->rd_indcollation[i]))
 			giststate->supportCollation[i] = index->rd_indcollation[i];

src/backend/access/gist/gistget.c

@@ -71,7 +71,7 @@ gistindex_keytest(IndexScanDesc scan,
 		int			i;
 
 		if (GistPageIsLeaf(page))		/* shouldn't happen */
-			elog(ERROR, "invalid GIST tuple found on leaf page");
+			elog(ERROR, "invalid GiST tuple found on leaf page");
 		for (i = 0; i < scan->numberOfOrderBys; i++)
 			so->distances[i] = -get_float8_infinity();
 		return true;

src/backend/access/gist/gistxlog.c

@@ -306,7 +306,7 @@ gist_redo(XLogRecPtr lsn, XLogRecord *record)
 	MemoryContext oldCxt;
 
 	/*
-	 * GIST indexes do not require any conflict processing. NB: If we ever
+	 * GiST indexes do not require any conflict processing. NB: If we ever
 	 * implement a similar optimization we have in b-tree, and remove killed
 	 * tuples outside VACUUM, we'll need to handle that here.
 	 */

src/backend/catalog/sql_features.txt

@@ -397,7 +397,7 @@ T052	MAX and MIN for row types			NO
 T053	Explicit aliases for all-fields reference			NO	
 T061	UCS support			NO	
 T071	BIGINT data type			YES	
-T101	Enhanced nullability determiniation			NO	
+T101	Enhanced nullability determination			NO	
 T111	Updatable joins, unions, and columns			NO	
 T121	WITH (excluding RECURSIVE) in query expression			YES	
 T122	WITH (excluding RECURSIVE) in subquery			YES	

src/backend/commands/indexcmds.c

@@ -287,7 +287,7 @@ DefineIndex(RangeVar *heapRelation,
 	{
 		/*
 		 * Hack to provide more-or-less-transparent updating of old RTREE
-		 * indexes to GIST: if RTREE is requested and not found, use GIST.
+		 * indexes to GiST: if RTREE is requested and not found, use GIST.
 		 */
 		if (strcmp(accessMethodName, "rtree") == 0)
 		{

src/test/regress/expected/opr_sanity.out

@@ -1177,7 +1177,7 @@ WHERE p1.amprocfamily = p3.oid AND p3.opfmethod = p2.oid AND
 
 -- Detect missing pg_amproc entries: should have as many support functions
 -- as AM expects for each datatype combination supported by the opfamily.
--- GIST/GIN are special cases because each has an optional support function.
+-- GiST/GIN are special cases because each has an optional support function.
 SELECT p1.amname, p2.opfname, p3.amproclefttype, p3.amprocrighttype
 FROM pg_am AS p1, pg_opfamily AS p2, pg_amproc AS p3
 WHERE p2.opfmethod = p1.oid AND p3.amprocfamily = p2.oid AND
@@ -1190,7 +1190,7 @@ WHERE p2.opfmethod = p1.oid AND p3.amprocfamily = p2.oid AND
 --------+---------+----------------+-----------------
 (0 rows)
 
--- Similar check for GIST/GIN, allowing one optional proc
+-- Similar check for GiST/GIN, allowing one optional proc
 SELECT p1.amname, p2.opfname, p3.amproclefttype, p3.amprocrighttype
 FROM pg_am AS p1, pg_opfamily AS p2, pg_amproc AS p3
 WHERE p2.opfmethod = p1.oid AND p3.amprocfamily = p2.oid AND
@@ -1205,7 +1205,7 @@ WHERE p2.opfmethod = p1.oid AND p3.amprocfamily = p2.oid AND
 (0 rows)
 
 -- Also, check if there are any pg_opclass entries that don't seem to have
--- pg_amproc support.  Again, GIST/GIN have to be checked specially.
+-- pg_amproc support.  Again, GiST/GIN have to be checked specially.
 SELECT amname, opcname, count(*)
 FROM pg_am am JOIN pg_opclass op ON opcmethod = am.oid
      LEFT JOIN pg_amproc p ON amprocfamily = opcfamily AND

src/test/regress/sql/opr_sanity.sql

@@ -920,7 +920,7 @@ WHERE p1.amprocfamily = p3.oid AND p3.opfmethod = p2.oid AND
 
 -- Detect missing pg_amproc entries: should have as many support functions
 -- as AM expects for each datatype combination supported by the opfamily.
--- GIST/GIN are special cases because each has an optional support function.
+-- GiST/GIN are special cases because each has an optional support function.
 
 SELECT p1.amname, p2.opfname, p3.amproclefttype, p3.amprocrighttype
 FROM pg_am AS p1, pg_opfamily AS p2, pg_amproc AS p3
@@ -931,7 +931,7 @@ WHERE p2.opfmethod = p1.oid AND p3.amprocfamily = p2.oid AND
                            p4.amproclefttype = p3.amproclefttype AND
                            p4.amprocrighttype = p3.amprocrighttype);
 
--- Similar check for GIST/GIN, allowing one optional proc
+-- Similar check for GiST/GIN, allowing one optional proc
 
 SELECT p1.amname, p2.opfname, p3.amproclefttype, p3.amprocrighttype
 FROM pg_am AS p1, pg_opfamily AS p2, pg_amproc AS p3
@@ -944,7 +944,7 @@ WHERE p2.opfmethod = p1.oid AND p3.amprocfamily = p2.oid AND
       NOT IN (p1.amsupport, p1.amsupport - 1);
 
 -- Also, check if there are any pg_opclass entries that don't seem to have
--- pg_amproc support.  Again, GIST/GIN have to be checked specially.
+-- pg_amproc support.  Again, GiST/GIN have to be checked specially.
 
 SELECT amname, opcname, count(*)
 FROM pg_am am JOIN pg_opclass op ON opcmethod = am.oid