Remove completed items, and the last is unwanted:

bmomjian · bmomjian · commit 62c06186f55f · 2007-01-13T15:13:44.000Z
< o Fix memory leak from exceptions < < http://archives.postgresql.org/pgsql-performance/2006-06/msg00305.php < < * Allow constraint_exclusion to work for UNIONs like it does for < inheritance, allow it to work for UPDATE and DELETE statements, and allow < it to be used for all statements with little performance impact < < * Add estimated_count(*) to return an estimate of COUNT(*) < < This would use the planner ANALYZE statistics to return an estimated < count. < http://archives.postgresql.org/pgsql-hackers/2005-11/msg00943.php
diff --git a/doc/TODO b/doc/TODO
@@ -2,7 +2,7 @@
 PostgreSQL TODO List
 ====================
 Current maintainer:	Bruce Momjian (bruce@momjian.us)
-Last updated:		Wed Jan 10 23:48:50 EST 2007
+Last updated:		Sat Jan 13 10:13:24 EST 2007
 
 The most recent version of this document can be viewed at
 http://www.postgresql.org/docs/faqs.TODO.html.
@@ -680,10 +680,6 @@ SQL Commands
 
 		  http://archives.postgresql.org/pgsql-patches/2005-11/msg00045.php
 
-		o Fix memory leak from exceptions
-
-		  http://archives.postgresql.org/pgsql-performance/2006-06/msg00305.php
-
 		o Fix problems with RETURN NEXT on tables with
 		  dropped/added columns after function creation
 
@@ -897,9 +893,6 @@ Indexes
   one column or expression indexes, perhaps using per-index statistics
 * -Allow the creation of indexes with mixed ascending/descending
   specifiers
-* Allow constraint_exclusion to work for UNIONs like it does for
-  inheritance, allow it to work for UPDATE and DELETE statements, and allow
-  it to be used for all statements with little performance impact
 * Consider compressing indexes by storing key values duplicated in
   several rows as a single index entry
 
@@ -979,12 +972,6 @@ Cache Usage
   faster than a sequential scan it must avoid access to the heap
   to obtain tuple visibility information.
 
-* Add estimated_count(*) to return an estimate of COUNT(*)
-
-  This would use the planner ANALYZE statistics to return an estimated
-  count.
-  http://archives.postgresql.org/pgsql-hackers/2005-11/msg00943.php
-
 * Allow data to be pulled directly from indexes
 
   Currently indexes do not have enough tuple visibility information 
diff --git a/doc/src/FAQ/TODO.html b/doc/src/FAQ/TODO.html
@@ -8,7 +8,7 @@
 <body bgcolor="#FFFFFF" text="#000000" link="#FF0000" vlink="#A00000" alink="#0000FF">
 <h1><a name="section_1">PostgreSQL TODO List</a></h1>
 <p>Current maintainer:     Bruce Momjian (<a href="mailto:bruce@momjian.us">bruce@momjian.us</a>)<br/>
-Last updated:           Wed Jan 10 23:48:50 EST 2007
+Last updated:           Sat Jan 13 10:13:24 EST 2007
 </p>
 <p>The most recent version of this document can be viewed at<br/>
 <a href="http://www.postgresql.org/docs/faqs.TODO.html">http://www.postgresql.org/docs/faqs.TODO.html</a>.
@@ -614,9 +614,6 @@ <h1><a name="section_8">SQL Commands</a></h1>
 </p>
       </li><li>Allow PL/RETURN to return row or record functions
 <p>                  <a href="http://archives.postgresql.org/pgsql-patches/2005-11/msg00045.php">http://archives.postgresql.org/pgsql-patches/2005-11/msg00045.php</a>
-</p>
-      </li><li>Fix memory leak from exceptions
-<p>                  <a href="http://archives.postgresql.org/pgsql-performance/2006-06/msg00305.php">http://archives.postgresql.org/pgsql-performance/2006-06/msg00305.php</a>
 </p>
       </li><li>Fix problems with RETURN NEXT on tables with
                   dropped/added columns after function creation
@@ -810,9 +807,6 @@ <h1><a name="section_12">Indexes</a></h1>
   one column or expression indexes, perhaps using per-index statistics
   </li><li>-<em>Allow the creation of indexes with mixed ascending/descending</em>
   specifiers
-  </li><li>Allow constraint_exclusion to work for UNIONs like it does for
-  inheritance, allow it to work for UPDATE and DELETE statements, and allow
-  it to be used for all statements with little performance impact
   </li><li>Consider compressing indexes by storing key values duplicated in
   several rows as a single index entry
 <p>  This is difficult because it requires datatype-specific knowledge.
@@ -879,11 +873,6 @@ <h1><a name="section_14">Cache Usage</a></h1>
   get a count directly from a unique index, but for this to be
   faster than a sequential scan it must avoid access to the heap
   to obtain tuple visibility information.
-</p>
-  </li><li>Add estimated_count(*) to return an estimate of COUNT(*)
-<p>  This would use the planner ANALYZE statistics to return an estimated
-  count.
-  <a href="http://archives.postgresql.org/pgsql-hackers/2005-11/msg00943.php">http://archives.postgresql.org/pgsql-hackers/2005-11/msg00943.php</a>
 </p>
   </li><li>Allow data to be pulled directly from indexes
 <p>  Currently indexes do not have enough tuple visibility information 
