Make source code READMEs more consistent. Add CVS tags to all README files.

src/backend/access/gin/README

+$PostgreSQL: pgsql/src/backend/access/gin/README,v 1.5 2008/03/20 17:55:14 momjian Exp $
+
 Gin for PostgreSQL
 ==================
 

src/backend/access/gist/README

-$PostgreSQL: pgsql/src/backend/access/gist/README,v 1.3 2005/09/16 14:40:54 teodor Exp $
+$PostgreSQL: pgsql/src/backend/access/gist/README,v 1.4 2008/03/20 17:55:14 momjian Exp $
+
+GiST Indexing
+=============
 
 This directory contains an implementation of GiST indexing for Postgres.
 
@@ -48,7 +51,8 @@ core and PostgreSQL WAL system. Moreover, we encountered (and solved)
 a problem of uncompleted insertions when recovering after crash, which
 was not touched in the paper.
 
-SEARCH ALGORITHM
+Search Algorithm
+----------------
 
 Function gettuple finds a tuple which satisfies the search
 predicate. It store their state and returns next tuple under
@@ -92,7 +96,8 @@ gettuple(search-pred)
 	end
 
 
-INSERT ALGORITHM
+Insert Algorithm
+----------------
 
 INSERT guarantees that the GiST tree remains balanced. User defined key method 
 Penalty is used for choosing a subtree to insert; method PickSplit is used for 

src/backend/access/hash/README

-$PostgreSQL: pgsql/src/backend/access/hash/README,v 1.7 2008/03/15 20:46:31 tgl Exp $
+$PostgreSQL: pgsql/src/backend/access/hash/README,v 1.8 2008/03/20 17:55:14 momjian Exp $
+
+Hash Indexing
+=============
 
 This directory contains an implementation of hash indexing for Postgres.  Most
 of the core ideas are taken from Margo Seltzer and Ozan Yigit, A New Hashing
@@ -30,7 +33,7 @@ in other buckets, but we never give them back to the operating system.
 There is no provision for reducing the number of buckets, either.
 
 
-Page addressing
+Page Addressing
 ---------------
 
 There are four kinds of pages in a hash index: the meta page (page zero),
@@ -111,7 +114,7 @@ first bitmap page, which is allocated during index creation just after all
 the initially created buckets.
 
 
-Lock definitions
+Lock Definitions
 ----------------
 
 We use both lmgr locks ("heavyweight" locks) and buffer context locks
@@ -166,7 +169,7 @@ be held at a time by any one process.  (The third restriction is probably
 stronger than necessary, but it makes the proof of no deadlock obvious.)
 
 
-Pseudocode algorithms
+Pseudocode Algorithms
 ---------------------
 
 The operations we need to support are: readers scanning the index for
@@ -324,7 +327,7 @@ The exclusive lock request could deadlock in some strange scenarios, but
 we can just error out without any great harm being done.
 
 
-Free space management
+Free Space Management
 ---------------------
 
 (Question: why is this so complicated?  Why not just have a linked list
@@ -429,7 +432,7 @@ All the freespace operations should be called while holding no buffer
 locks.  Since they need no lmgr locks, deadlock is not possible.
 
 
-Other notes
+Other Notes
 -----------
 
 All the shenanigans with locking prevent a split occurring while *another*

src/backend/access/nbtree/README

-$PostgreSQL: pgsql/src/backend/access/nbtree/README,v 1.18 2007/09/12 22:10:26 tgl Exp $
+$PostgreSQL: pgsql/src/backend/access/nbtree/README,v 1.19 2008/03/20 17:55:14 momjian Exp $
+
+Btree Indexing
+--------------
 
 This directory contains a correct implementation of Lehman and Yao's
 high-concurrency B-tree management algorithm (P. Lehman and S. Yao,
@@ -8,7 +11,7 @@ use a simplified version of the deletion logic described in Lanin and
 Shasha (V. Lanin and D. Shasha, A Symmetric Concurrent B-Tree Algorithm,
 Proceedings of 1986 Fall Joint Computer Conference, pp 380-389).
 
-The Lehman and Yao algorithm and insertions
+The Lehman and Yao Algorithm and Insertions
 -------------------------------------------
 
 We have made the following changes in order to incorporate the L&Y algorithm
@@ -125,7 +128,7 @@ each of the resulting pages.  Note we must include the incoming item in
 this calculation, otherwise it is possible to find that the incoming
 item doesn't fit on the split page where it needs to go!
 
-The deletion algorithm
+The Deletion Algorithm
 ----------------------
 
 Before deleting a leaf item, we get a super-exclusive lock on the target
@@ -320,7 +323,7 @@ positives, so long as it never gives a false negative.  This makes it
 possible to implement the test with a small counter value stored on each
 index page.
 
-On-the-fly deletion of index tuples
+On-the-Fly Deletion Of Index Tuples
 -----------------------------------
 
 If a process visits a heap tuple and finds that it's dead and removable
@@ -357,7 +360,7 @@ and so cannot remove the heap tuple.  This is another reason why
 btbulkdelete has to get super-exclusive lock on every leaf page, not only
 the ones where it actually sees items to delete.
 
-WAL considerations
+WAL Considerations
 ------------------
 
 The insertion and deletion algorithms in themselves don't guarantee btree
@@ -398,7 +401,7 @@ of the WAL entry.)  If the parent page becomes half-dead but is not
 immediately deleted due to a subsequent crash, there is no loss of
 consistency, and the empty page will be picked up by the next VACUUM.
 
-Other things that are handy to know
+Other Things That Are Handy to Know
 -----------------------------------
 
 Page zero of every btree is a meta-data page.  This page stores the
@@ -443,7 +446,7 @@ original search scankey is consulted as each index entry is sequentially
 scanned to decide whether to return the entry and whether the scan can
 stop (see _bt_checkkeys()).
 
-Notes about data representation
+Notes About Data Representation
 -------------------------------
 
 The right-sibling link required by L&Y is kept in the page "opaque
@@ -477,7 +480,7 @@ item is irrelevant, and need not be stored at all.  This arrangement
 corresponds to the fact that an L&Y non-leaf page has one more pointer
 than key.
 
-Notes to operator class implementors
+Notes to Operator Class Implementors
 ------------------------------------
 
 With this implementation, we require each supported combination of

src/backend/access/transam/README

-$PostgreSQL: pgsql/src/backend/access/transam/README,v 1.9 2007/09/08 20:31:14 tgl Exp $
+$PostgreSQL: pgsql/src/backend/access/transam/README,v 1.10 2008/03/20 17:55:14 momjian Exp $
 
 The Transaction System
 ----------------------
@@ -145,7 +145,7 @@ finishing of transactions and subtransactions.  For example, AtStart_Memory
 takes care of initializing the memory subsystem at main transaction start.
 
 
-Subtransaction handling
+Subtransaction Handling
 -----------------------
 
 Subtransactions are implemented using a stack of TransactionState structures,
@@ -187,7 +187,7 @@ Another difference is that BeginInternalSubtransaction is allowed when no
 explicit transaction block has been established, while DefineSavepoint is not.
 
 
-Transaction and subtransaction numbering
+Transaction and Subtransaction Numbering
 ----------------------------------------
 
 Transactions and subtransactions are assigned permanent XIDs only when/if
@@ -221,7 +221,7 @@ InvalidSubTransactionId.)  Note that subtransactions do not have their
 own VXIDs; they use the parent top transaction's VXID.
 
 
-Interlocking transaction begin, transaction end, and snapshots
+Interlocking Transaction Begin, Transaction End, and Snapshots
 --------------------------------------------------------------
 
 We try hard to minimize the amount of overhead and lock contention involved
@@ -375,7 +375,7 @@ for pg_clog are implemented in transam.c, while the low-level functions are in
 clog.c.  pg_subtrans is contained completely in subtrans.c.
 
 
-Write-Ahead Log coding
+Write-Ahead Log Coding
 ----------------------
 
 The WAL subsystem (also called XLOG in the code) exists to guarantee crash

src/backend/catalog/README

-$PostgreSQL: pgsql/src/backend/catalog/README,v 1.11 2007/05/11 17:57:11 tgl Exp $
+$PostgreSQL: pgsql/src/backend/catalog/README,v 1.12 2008/03/20 17:55:14 momjian Exp $
+
+System Catalog
+--------------
 
 This directory contains .c files that manipulate the system catalogs;
 src/include/catalog contains the .h files that define the structure

src/backend/executor/README

-$PostgreSQL: pgsql/src/backend/executor/README,v 1.5 2005/04/28 21:47:12 tgl Exp $
+$PostgreSQL: pgsql/src/backend/executor/README,v 1.6 2008/03/20 17:55:14 momjian Exp $
 
 The Postgres Executor
 ---------------------
@@ -137,7 +137,7 @@ be hidden inside function calls).  This case has a flow of control like
 		(a separate FreeExprContext call is not necessary)
 
 
-EvalPlanQual (READ COMMITTED update checking)
+EvalPlanQual (READ COMMITTED Update Checking)
 ---------------------------------------------
 
 For simple SELECTs, the executor need only pay attention to tuples that are

src/backend/nodes/README

-*******************************************************************************
-*                                                                             *
-* EXPLANATION OF THE NODE STRUCTURES                                          *
-*    - Andrew Yu (11/94)                                                      *
-*                                                                             *
-* Copyright (c) 1994, Regents of the University of California                 *
-*                                                                             *
-* $PostgreSQL: pgsql/src/backend/nodes/README,v 1.2 2003/11/29 22:39:45 pgsql Exp $
-*                                                                             *
-*******************************************************************************
-
-INTRODUCTION
+$PostgreSQL: pgsql/src/backend/nodes/README,v 1.3 2008/03/20 17:55:14 momjian Exp $
+
+Node Structures
+===============
+
+Andrew Yu (11/94)
+
+Introduction
+------------
 
 The current node structures are plain old C structures. "Inheritance" is
 achieved by convention. No additional functions will be generated. Functions
@@ -36,7 +33,8 @@ FILES IN THIS DIRECTORY
 	memnodes.h	- memory nodes
 
 
-STEPS TO ADD A NODE
+Steps to Add a Node
+-------------------
 
 Suppose you wana define a node Foo:
 
@@ -51,7 +49,8 @@ Suppose you wana define a node Foo:
    bother writing a creator function in makefuncs.c)
 
 
-HISTORICAL NOTE
+Historical Note
+---------------
 
 Prior to the current simple C structure definitions, the Node structures 
 uses a pseudo-inheritance system which automatically generates creator and

src/backend/optimizer/README

-Summary
--------
+$PostgreSQL: pgsql/src/backend/optimizer/README,v 1.42 2008/03/20 17:55:14 momjian Exp $
+
+Optimizer
+---------
 
 These directories take the Query structure returned by the parser, and
 generate a plan used by the executor.  The /plan directory generates the
@@ -180,7 +182,7 @@ to see which join style should be applied for a valid join, ie,
 JOIN_INNER, JOIN_LEFT, etc.)
 
 
-Valid OUTER JOIN optimizations
+Valid OUTER JOIN Optimizations
 ------------------------------
 
 The planner's treatment of outer join reordering is based on the following
@@ -236,7 +238,7 @@ set must be expanded to include the whole of the lower OJ, thereby
 preventing it from being formed before the lower OJ is.)
 
 
-Pulling up subqueries
+Pulling Up Subqueries
 ---------------------
 
 As we described above, a subquery appearing in the range table is planned

src/backend/optimizer/plan/README

-Subselect notes from Vadim.
+$PostgreSQL: pgsql/src/backend/optimizer/plan/README,v 1.2 2008/03/20 17:55:14 momjian Exp $
 
+Subselects
+----------
+
+Vadim B. Mikheev
 
 
 From owner-pgsql-hackers@hub.org Fri Feb 13 09:01:19 1998
 Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
 	by candle.pha.pa.us (8.8.5/8.8.5) with ESMTP id JAA11576
 	for <maillist@candle.pha.pa.us>; Fri, 13 Feb 1998 09:01:17 -0500 (EST)
-Received: from hub.org (hub.org [209.47.148.200]) by renoir.op.net (o1/$Revision: 1.1 $) with ESMTP id IAA09761 for <maillist@candle.pha.pa.us>; Fri, 13 Feb 1998 08:41:22 -0500 (EST)
+Received: from hub.org (hub.org [209.47.148.200]) by renoir.op.net (o1/$Revision: 1.2 $) with ESMTP id IAA09761 for <maillist@candle.pha.pa.us>; Fri, 13 Feb 1998 08:41:22 -0500 (EST)
 Received: from localhost (majordom@localhost) by hub.org (8.8.8/8.7.5) with SMTP id IAA08135; Fri, 13 Feb 1998 08:40:17 -0500 (EST)
 Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Fri, 13 Feb 1998 08:38:42 -0500 (EST)
 Received: (from majordom@localhost) by hub.org (8.8.8/8.7.5) id IAA06646 for pgsql-hackers-outgoing; Fri, 13 Feb 1998 08:38:35 -0500 (EST)

src/backend/parser/README

+$PostgreSQL: pgsql/src/backend/parser/README,v 1.6 2008/03/20 17:55:14 momjian Exp $
+
+Parser
+------
+
 This directory does more than tokenize and parse SQL queries.  It also
 creates Query structures for the various complex queries that are passed
 to the optimizer and then executor.

src/backend/port/darwin/README

+$PostgreSQL: pgsql/src/backend/port/darwin/README,v 1.4 2008/03/20 17:55:14 momjian Exp $
+
+Darwin
+------
+
 The file system.c included herein is taken directly from Apple's Darwin
 open-source CVS archives, and is redistributed under the BSD copyright
 notice it bears.  (According to Apple's CVS logs, their version is

src/backend/snowball/README

-Snowball-based stemming
+$PostgreSQL: pgsql/src/backend/snowball/README,v 1.2 2008/03/20 17:55:14 momjian Exp $
+
+Snowball-Based Stemming
 -----------------------
 
 This module uses the word stemming code developed by the Snowball project,

src/backend/storage/buffer/README

-$PostgreSQL: pgsql/src/backend/storage/buffer/README,v 1.12 2007/05/30 20:11:58 tgl Exp $
+$PostgreSQL: pgsql/src/backend/storage/buffer/README,v 1.13 2008/03/20 17:55:15 momjian Exp $
 
-Notes about shared buffer access rules
+Notes About Shared Buffer Access Rules
 --------------------------------------
 
 There are two separate access control mechanisms for shared disk buffers:
@@ -92,7 +92,7 @@ for VACUUM's use, since we don't allow multiple VACUUMs concurrently on a
 single relation anyway.
 
 
-Buffer manager's internal locking
+Buffer Manager's Internal Locking
 ---------------------------------
 
 Before PostgreSQL 8.1, all operations of the shared buffer manager itself
@@ -152,7 +152,7 @@ we could use per-backend LWLocks instead (a buffer header would then contain
 a field to show which backend is doing its I/O).
 
 
-Normal buffer replacement strategy
+Normal Buffer Replacement Strategy
 ----------------------------------
 
 There is a "free list" of buffers that are prime candidates for replacement.
@@ -201,7 +201,7 @@ have to give up and try another buffer.  This however is not a concern
 of the basic select-a-victim-buffer algorithm.)
 
 
-Buffer ring replacement strategy
+Buffer Ring Replacement Strategy
 ---------------------------------
 
 When running a query that needs to access a large number of pages just once,
@@ -236,7 +236,7 @@ buffer, resulting in excessive WAL flushing.  Allowing VACUUM to update
 256KB between WAL flushes should be more efficient.
 
 
-Background writer's processing
+Background Writer's Processing
 ------------------------------
 
 The background writer is designed to write out pages that are likely to be

src/backend/storage/ipc/README

-$PostgreSQL: pgsql/src/backend/storage/ipc/README,v 1.4 2003/11/29 19:51:56 pgsql Exp $
-Mon Jul 18 11:09:22 PDT 1988  W.KLAS
+$PostgreSQL: pgsql/src/backend/storage/ipc/README,v 1.5 2008/03/20 17:55:15 momjian Exp $
 
-Cache invalidation synchronization routines:
+Cache Invalidation Synchronization Routines
 ===========================================
 
+Mon Jul 18 11:09:22 PDT 1988  W.KLAS
+
 The cache synchronization is done using a message queue. Every
 backend can register a message which then has to be read by
 all backends. A message read by all backends is removed from the 

src/backend/storage/lmgr/README

-$PostgreSQL: pgsql/src/backend/storage/lmgr/README,v 1.22 2007/10/26 20:45:10 alvherre Exp $
+$PostgreSQL: pgsql/src/backend/storage/lmgr/README,v 1.23 2008/03/20 17:55:15 momjian Exp $
 
-
-LOCKING OVERVIEW
+Locking Overview
+----------------
 
 Postgres uses three types of interprocess locks:
 
@@ -45,7 +45,8 @@ when the wait time might exceed a few seconds.
 The rest of this README file discusses the regular lock manager in detail.
 
 
-LOCK DATA STRUCTURES
+Lock Data Structures
+--------------------
 
 Lock methods describe the overall locking behavior.  Currently there are
 two lock methods: DEFAULT and USER.
@@ -187,7 +188,8 @@ procLink -
 ---------------------------------------------------------------------------
 
 
-LOCK MANAGER INTERNAL LOCKING
+Lock Manager Internal Locking
+-----------------------------
 
 Before PostgreSQL 8.2, all of the shared-memory data structures used by
 the lock manager were protected by a single LWLock, the LockMgrLock;
@@ -246,7 +248,8 @@ tradeoff: we could instead recalculate the partition number from the LOCKTAG
 when needed.
 
 
-THE DEADLOCK DETECTION ALGORITHM
+The Deadlock Detection Algorithm
+--------------------------------
 
 Since we allow user transactions to request locks in any order, deadlock
 is possible.  We use a deadlock detection/breaking algorithm that is
@@ -445,7 +448,8 @@ eventually lead to the discovery of the additional constraint B before C.)
 
 Got that?
 
-Miscellaneous notes:
+Miscellaneous Notes
+-------------------
 
 1. It is easily proven that no deadlock will be missed due to our
 asynchronous invocation of deadlock checking.  A deadlock cycle in the WFG
@@ -495,7 +499,8 @@ The caller can then send a cancellation signal.  This implements the
 principle that autovacuum has a low locking priority (eg it must not block
 DDL on the table).
 
-USER LOCKS
+User Locks
+----------
 
 User locks are handled totally on the application side as long term
 cooperative locks which extend beyond the normal transaction boundaries.

src/backend/storage/smgr/README

-# $PostgreSQL: pgsql/src/backend/storage/smgr/README,v 1.3 2004/02/10 01:55:26 tgl Exp $
+# $PostgreSQL: pgsql/src/backend/storage/smgr/README,v 1.4 2008/03/20 17:55:15 momjian Exp $
+
+Storage Manager
+---------------
 
 In the original Berkeley Postgres system, there were several storage managers,
 of which only the "magnetic disk" manager remains.  (At Berkeley there were

src/backend/utils/fmgr/README

-Proposal for function-manager redesign			19-Nov-2000
+$PostgreSQL: pgsql/src/backend/utils/fmgr/README,v 1.10 2008/03/20 17:55:15 momjian Exp $
+
+Function Manager
+================
+
+Proposal For Function-Manager Redesign			19-Nov-2000
 --------------------------------------
 
 We know that the existing mechanism for calling Postgres functions needs
@@ -25,7 +30,7 @@ written in the old style can be left in place indefinitely, to provide
 backward compatibility for user-written C functions.
 
 
-Changes in pg_proc (system data about a function)
+Changes In pg_proc (System Data About a Function)
 -------------------------------------------------
 
 A new column "proisstrict" will be added to the system pg_proc table.
@@ -45,7 +50,7 @@ more useful case for functions expressed in SQL or a PL language, but
 am open to arguments for the other choice.
 
 
-The new function-manager interface
+The New Function-Manager Interface
 ----------------------------------
 
 The core of the new design is revised data structures for representing
@@ -165,7 +170,7 @@ through a function pointer declared with exactly that signature, we
 should have no portability or optimization problems.
 
 
-Function coding conventions
+Function Coding Conventions
 ---------------------------
 
 As an example, int4 addition goes from old-style
@@ -277,7 +282,7 @@ fields of FunctionCallInfo, it should just do it.  I doubt that providing
 syntactic-sugar macros for these cases is useful.
 
 
-Call-site coding conventions
+Call-Site Coding Conventions
 ----------------------------
 
 There are many places in the system that call either a specific function
@@ -339,7 +344,7 @@ have to change in the first step of implementation, but they can
 continue to support the same external appearance.
 
 
-Support for TOAST-able data types
+Support for TOAST-Able Data Types
 ---------------------------------
 
 For TOAST-able data types, the PG_GETARG macro will deliver a de-TOASTed
@@ -372,7 +377,7 @@ context.  When and if the value is actually stored into a tuple, the
 tuple toaster will decide whether toasting is needed.
 
 
-Functions accepting or returning sets
+Functions Accepting or Returning Sets
 -------------------------------------
 
 [ this section revised 29-Aug-2002 for 7.3 ]
@@ -436,7 +441,7 @@ There is no support for functions accepting sets; instead, the function will
 be called multiple times, once for each element of the input set.
 
 
-Notes about function handlers
+Notes About Function Handlers
 -----------------------------
 
 Handlers for classes of functions should find life much easier and
@@ -458,7 +463,7 @@ in any case it is required to be a context at least as long-lived as the
 FmgrInfo itself.
 
 
-Telling the difference between old- and new-style functions
+Telling the Difference Between Old- and New-Style Functions
 -----------------------------------------------------------
 
 During the conversion process, we carried two different pg_language

src/backend/utils/mb/README

+$PostgreSQL: pgsql/src/backend/utils/mb/README,v 1.6 2008/03/20 17:55:15 momjian Exp $
+
+Encodings
+---------
+
 encnames.c:	public functions for both the backend and the frontend.
 conv.c:		static functions and a public table for code conversion
 wchar.c:	mostly static functions and a public table for mb string and

src/backend/utils/misc/README

-$PostgreSQL: pgsql/src/backend/utils/misc/README,v 1.9 2008/03/16 16:42:44 mha Exp $
+$PostgreSQL: pgsql/src/backend/utils/misc/README,v 1.10 2008/03/20 17:55:15 momjian Exp $
 
-
-GUC IMPLEMENTATION NOTES
+Guc Implementation Notes
+========================
 
 The GUC (Grand Unified Configuration) module implements configuration
 variables of multiple types (currently boolean, enum, int, float, and string).
@@ -9,7 +9,8 @@ Variable settings can come from various places, with a priority ordering
 determining which setting is used.
 
 
-PER-VARIABLE HOOKS
+Per-Variable Hooks
+------------------
 
 Each variable known to GUC can optionally have an assign_hook and/or
 a show_hook to provide customized behavior.  Assign hooks are used to
@@ -69,7 +70,8 @@ This hook allows variable-specific computation of the value displayed
 by SHOW.
 
 
-SAVING/RESTORING GUC VARIABLE VALUES
+Saving/Restoring Guc Variable Values
+------------------------------------
 
 Prior values of configuration variables must be remembered in order to deal
 with several special cases: RESET (a/k/a SET TO DEFAULT), rollback of SET
@@ -208,7 +210,8 @@ with doit = false so that the value is validated, but no derived state is
 changed.
 
 
-STRING MEMORY HANDLING
+String Memory Handling
+----------------------
 
 String option values are allocated with strdup, not with the
 pstrdup/palloc mechanisms.  We would need to keep them in a permanent

src/backend/utils/mmgr/README

-$PostgreSQL: pgsql/src/backend/utils/mmgr/README,v 1.11 2007/05/29 04:19:35 neilc Exp $
+$PostgreSQL: pgsql/src/backend/utils/mmgr/README,v 1.12 2008/03/20 17:55:15 momjian Exp $
 
-Notes about memory allocation redesign
---------------------------------------
+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
@@ -53,7 +53,7 @@ that can be reset or deleted at strategic times within a query, such as
 after each tuple.
 
 
-Some notes about the palloc API versus standard C library
+Some Notes About the palloc API Versus Standard C Library
 ---------------------------------------------------------
 
 The behavior of palloc and friends is similar to the standard C library's
@@ -73,7 +73,7 @@ Similarly, repalloc allows realloc'ing to zero size.
 * pfree and repalloc do not accept a NULL pointer.  This is intentional.
 
 
-pfree/repalloc no longer depend on CurrentMemoryContext
+pfree/repalloc No Longer Depend On CurrentMemoryContext
 -------------------------------------------------------
 
 In this proposal, pfree() and repalloc() can be applied to any chunk
@@ -101,7 +101,7 @@ do".  So there'd still need to be a global variable specifying a suitable
 temporary-allocation context.  That might as well be CurrentMemoryContext.
 
 
-Additions to the memory-context mechanism
+Additions to the Memory-Context Mechanism
 -----------------------------------------
 
 If we are going to have more contexts, we need more mechanism for keeping
@@ -130,7 +130,7 @@ children of a given context, but don't reset or delete that context
 itself".
 
 
-Globally known contexts
+Globally Known Contexts
 -----------------------
 
 There will be several widely-known contexts that will typically be
@@ -214,7 +214,7 @@ if the backend has run out of memory otherwise.  This allows out-of-memory
 to be treated as a normal ERROR condition, not a FATAL error.
 
 
-Contexts for prepared statements and portals
+Contexts For Prepared Statements And Portals
 --------------------------------------------
 
 A prepared-statement object has an associated private context, in which
@@ -230,7 +230,7 @@ from prepared statements simply reference the prepared statements' trees,
 and won't actually need any storage allocated in their private contexts.
 
 
-Transient contexts during execution
+Transient Contexts During Execution
 -----------------------------------
 
 When creating a prepared statement, the parse and plan trees will be built
@@ -318,7 +318,7 @@ processing.  (Eventually we might have an even better solution from
 nested transactions, but this'll do fine for now.)
 
 
-Mechanisms to allow multiple types of contexts
+Mechanisms to Allow Multiple Types of Contexts
 ----------------------------------------------
 
 We may want several different types of memory contexts with different
@@ -389,7 +389,7 @@ compared to the existing code, so I think we're doing fine without
 squeezing out that last little bit ...
 
 
-More control over aset.c behavior
+More Control Over aset.c Behavior
 ---------------------------------
 
 Currently, aset.c allocates an 8K block upon the first allocation in
@@ -417,7 +417,7 @@ back to malloc() during reset, but just cleared.  This avoids malloc
 thrashing.
 
 
-Other notes
+Other Notes
 -----------
 
 The original version of this proposal suggested that functions returning

src/backend/utils/resowner/README

-$PostgreSQL: pgsql/src/backend/utils/resowner/README,v 1.5 2007/03/13 00:33:42 tgl Exp $
+$PostgreSQL: pgsql/src/backend/utils/resowner/README,v 1.6 2008/03/20 17:55:15 momjian Exp $
 
-Notes about resource owners
+Notes About Resource Owners
 ---------------------------
 
 ResourceOwner objects are a concept invented to simplify management of
@@ -39,7 +39,7 @@ because transactions may initiate operations that require resources (such
 as query parsing) when no associated Portal exists yet.
 
 
-API overview
+API Overview
 ------------
 
 The basic operations on a ResourceOwner are: