]> granicus.if.org Git - postgresql/commitdiff
Fix some typos in the TODO list.
authorNeil Conway <neilc@samurai.com>
Fri, 16 Dec 2005 18:44:07 +0000 (18:44 +0000)
committerNeil Conway <neilc@samurai.com>
Fri, 16 Dec 2005 18:44:07 +0000 (18:44 +0000)
doc/TODO

index 2300df8151bcbc440795f87558dbe19a0f539139..fcecf0a6f40b6999a1ab673e70bca0ebbe86be5f 100644 (file)
--- a/doc/TODO
+++ b/doc/TODO
@@ -135,7 +135,7 @@ Administration
            pg_stop_backup() is called or the server is stopped
 
            Doing this will allow administrators to know more easily when
-           the archive contins all the files needed for point-in-time
+           the archive contains all the files needed for point-in-time
            recovery.
 
          o %Create dump tool for write-ahead logs for use in determining
@@ -185,7 +185,7 @@ Data Types
 * Fix data types where equality comparison isn't intuitive, e.g. box
 * %Prevent INET cast to CIDR if the unmasked bits are not zero, or
   zero the bits
-* %Prevent INET cast to CIDR from droping netmask, SELECT '1.1.1.1'::inet::cidr
+* %Prevent INET cast to CIDR from dropping netmask, SELECT '1.1.1.1'::inet::cidr
 * Allow INET + INT4 to increment the host part of the address, or
   throw an error on overflow
 * %Add 'tid != tid ' operator for use in corruption recovery
@@ -457,7 +457,7 @@ SQL Commands
 
          This might require some background daemon to maintain clustering
          during periods of low usage. It might also require tables to be only
-         paritally filled for easier reorganization.  Another idea would
+         partially filled for easier reorganization.  Another idea would
           be to create a merged heap/index data file so an index lookup would
          automatically access the heap data too.  A third idea would be to
          store heap rows in hashed groups, perhaps using a user-supplied
@@ -592,7 +592,7 @@ Clients
 
          Currently, while \e saves a single statement as one entry, interactive
          statements are saved one line at a time.  Ideally all statements
-         whould be saved like \e does.
+         would be saved like \e does.
 
        o Allow multi-line column values to align in the proper columns
 
@@ -664,10 +664,10 @@ libpq
 
        o Allow statement results to be automatically batched to the client
 
-         Currently, all statement results are transfered to the libpq
+         Currently, all statement results are transferred to the libpq
          client before libpq makes the results available to the 
          application.  This feature would allow the application to make
-         use of the first result rows while the rest are transfered, or
+         use of the first result rows while the rest are transferred, or
          held on the server waiting for them to be requested by libpq.
          One complexity is that a statement like SELECT 1/col could error
          out mid-way through the result set.
@@ -743,7 +743,7 @@ Exotic Features
 
 * Add the features of packages
 
-       o  Make private objects accessable only to objects in the same schema
+       o  Make private objects accessible only to objects in the same schema
        o  Allow current_schema.objname to access current schema objects
        o  Add session variables
        o  Allow nested schemas
@@ -854,7 +854,7 @@ Cache Usage
 
 * Add estimated_count(*) to return an estimate of COUNT(*)
 
-  This would use the planner ANALYZE statistatics to return an estimated
+  This would use the planner ANALYZE statistics to return an estimated
   count.
 
 * Allow data to be pulled directly from indexes
@@ -880,7 +880,7 @@ Cache Usage
        o Query results
 
 * Allow sequential scans to take advantage of other concurrent
-  sequentiqal scans, also called "Synchronised Scanning"
+  sequential scans, also called "Synchronised Scanning"
 
   One possible implementation is to start sequential scans from the lowest
   numbered buffer in the shared cache, and when reaching the end wrap
@@ -893,7 +893,7 @@ Vacuum
 
 * Improve speed with indexes
 
-  For large table adjustements during VACUUM FULL, it is faster to 
+  For large table adjustments during VACUUM FULL, it is faster to 
   reindex rather than update the index.
 
 * Reduce lock time during VACUUM FULL by moving tuples with read lock,
@@ -942,7 +942,7 @@ Startup Time Improvements
 
   This would prevent the overhead associated with process creation. Most
   operating systems have trivial process creation time compared to
-  database startup overhead, but a few operating systems (WIn32,
+  database startup overhead, but a few operating systems (Win32,
   Solaris) might benefit from threading.  Also explore the idea of
   a single session using multiple threads to execute a statement faster.