diff --git a/doc/TODO b/doc/TODO
index 6b9fd4bbcd58ebe22c39ab77534cb547d8c9d71f..1b68a55501db4d9df641984eee647ec283d4c11c 100644
--- 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
index 42b23e22672fdf8b300e5e9fdef9c257d0a6646b..45e1b26546dee88d605db34a16bd15209a0a9366 100644
--- 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 @@ first.
</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 @@ first.
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 @@ first.
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