diff --git a/doc/src/FAQ/FAQ.html b/doc/src/FAQ/FAQ.html
index c8ac799189..ccd0f06b4f 100644
--- a/doc/src/FAQ/FAQ.html
+++ b/doc/src/FAQ/FAQ.html
@@ -10,7 +10,7 @@
alink="#0000ff">
<H1>Frequently Asked Questions (FAQ) for PostgreSQL</H1>
- <P>Last updated: Tue Apr 8 20:43:08 EDT 2008</P>
+ <P>Last updated: Mon Mar 3 11:22:50 EST 2008</P>
<P>Current maintainer: Bruce Momjian (<A href=
"mailto:bruce@momjian.us">bruce@momjian.us</A>)
@@ -150,8 +150,10 @@
http://www.postgresql.org/docs/faqs.FAQ_DEV.html</A>
</P>
- <P>Postgres is a widely-used nickname for PostgreSQL. If you find
- 'PostgreSQL' hard to pronounce, call it 'Postgres' instead.</P>
+ <P>Postgres is a widely-used nickname for PostgreSQL. It was the
+ original name of the project at Berkeley and is strongly preferred
+ over other nicknames. If you find 'PostgreSQL' hard to pronounce, call
+ it 'Postgres' instead.</P>
<H3 id="item1.2">1.2) Who controls PostgreSQL?<BR></H3>
diff --git a/src/backend/optimizer/README b/src/backend/optimizer/README
index ea13aeaa6e..3ea921f8f7 100644
--- a/src/backend/optimizer/README
+++ b/src/backend/optimizer/README
@@ -1,4 +1,4 @@
-$PostgreSQL: pgsql/src/backend/optimizer/README,v 1.43 2008/03/21 13:23:28 momjian Exp $
+$PostgreSQL: pgsql/src/backend/optimizer/README,v 1.44 2008/04/09 00:55:30 momjian Exp $
Optimizer
=========
@@ -73,8 +73,8 @@ tree is found by a recursive process:
1) Take each base relation in the query, and make a RelOptInfo structure
for it. Find each potentially useful way of accessing the relation,
-including sequential and index scans, and make a Path representing that
-way. All the Paths made for a given relation are placed in its
+including sequential and index scans, and make Paths representing those
+ways. All the Paths made for a given relation are placed in its
RelOptInfo.pathlist. (Actually, we discard Paths that are obviously
inferior alternatives before they ever get into the pathlist --- what
ends up in the pathlist is the cheapest way of generating each potentially
@@ -271,7 +271,7 @@ The primary entry point is planner().
planner()
set up for recursive handling of subqueries
- do final cleanup after planning.
+ do final cleanup after planning
-subquery_planner()
pull up subqueries from rangetable, if possible
canonicalize qual
diff --git a/src/backend/parser/README b/src/backend/parser/README
index f8ca493c13..e68c9d5277 100644
--- a/src/backend/parser/README
+++ b/src/backend/parser/README
@@ -1,4 +1,4 @@
-$PostgreSQL: pgsql/src/backend/parser/README,v 1.7 2008/03/21 13:23:28 momjian Exp $
+$PostgreSQL: pgsql/src/backend/parser/README,v 1.8 2008/04/09 00:55:30 momjian Exp $
Parser
======
@@ -14,7 +14,7 @@ keywords.c turn keywords into specific tokens
gram.y parse the tokens and fill query-type-specific structures
analyze.c top level of parse analysis for optimizable queries
parse_clause.c handle clauses like WHERE, ORDER BY, GROUP BY, ...
-parse_coerce.c handle coercing expressions to different types
+parse_coerce.c handle coercing expressions to different data types
parse_expr.c handle expressions like col, col + 3, x = 3 or x = 4
parse_oper.c handle operators in expressions
parse_agg.c handle aggregates, like SUM(col1), AVG(col2), ...
@@ -22,5 +22,5 @@ parse_func.c handle functions, table.column and column identifiers
parse_node.c create nodes for various structures
parse_target.c handle the result list of the query
parse_relation.c support routines for tables and column handling
-parse_type.c support routines for type handling
+parse_type.c support routines for data type handling
parse_utilcmd.c parse analysis for utility commands (done at execution time)
diff --git a/src/backend/utils/mmgr/README b/src/backend/utils/mmgr/README
index b681f9ce50..941b846754 100644
--- a/src/backend/utils/mmgr/README
+++ b/src/backend/utils/mmgr/README
@@ -1,14 +1,14 @@
-$PostgreSQL: pgsql/src/backend/utils/mmgr/README,v 1.12 2008/03/20 17:55:15 momjian Exp $
+$PostgreSQL: pgsql/src/backend/utils/mmgr/README,v 1.13 2008/04/09 00:55:30 momjian Exp $
Notes About Memory Allocation Redesign
======================================
Up through version 7.0, Postgres had serious problems with memory leakage
during large queries that process a lot of pass-by-reference data. There
-was no provision for recycling memory until end of query. This needs to be
-fixed, even more so with the advent of TOAST which will allow very large
+was no provision for recycling memory until end of query. This needed to be
+fixed, even more so with the advent of TOAST which will allowed very large
chunks of data to be passed around in the system. This document describes
-the new memory management plan implemented in 7.1.
+the new memory management system implemented in 7.1.
Background