This patch makes some minor improvements to the TODO list:

  * add URLs for some TODO items (I think we ought to try to associate
    at least one URL with each non-trivial TODO item)

  * re-add a TODO item for an "estimated count"-like facility

  * add a TODO item for considering changing how equality comparisons
    treat NaN values, per recent discussion

Barring any objections, I'll apply this to HEAD tomorrow.

-Neil

Index: doc/TODO
===================================================================
RCS file: /home/neilc/postgres/cvs_root/pgsql/doc/TODO,v
retrieving revision 1.2040
diff -c -p -r1.2040 TODO
*** doc/TODO	13 Jan 2007 15:13:44 -0000	1.2040
--- doc/TODO	15 Jan 2007 17:13:59 -0000
*************** Data Types
*** 185,190 ****
--- 185,196 ----
    The positive modulus result returned by NUMERICs might be considered
    inaccurate, in one sense.
  
+ * Consider changing equality comparison for numeric, float4, and
+   float8 to treat NaN in a way that is consistent with the
+   IEEE754 standard, perhaps by introducing an IS NAN construct.
+ 
+   http://archives.postgresql.org/pgsql-hackers/2007-01/msg00597.php
+ 
  * Fix data types where equality comparison isn't intuitive, e.g. box
  * Allow user-defined types to specify a type modifier at table creation
    time
*************** Functions
*** 341,347 ****
  * Add ISO day of week format 'ID' to to_char() where Monday = 1
  * Add a field 'isoyear' to extract(), based on the ISO week
  * Add SPI_gettypmod() to return the typemod for a TupleDesc
! * Allow inlining of set-returning functions
  * Allow SQL-language functions to return results from RETURNING queries
  
  
--- 347,353 ----
  * Add ISO day of week format 'ID' to to_char() where Monday = 1
  * Add a field 'isoyear' to extract(), based on the ISO week
  * Add SPI_gettypmod() to return the typemod for a TupleDesc
! * Implement inlining of set-returning functions defined in SQL
  * Allow SQL-language functions to return results from RETURNING queries
  
  
*************** Indexes
*** 928,933 ****
--- 934,941 ----
  	  several hash buckets could be stored on a single page and greater
  	  granularity used for the hash algorithm.
  
+ 	  http://archives.postgresql.org/pgsql-hackers/2004-06/msg00168.php
+ 
  	o Consider sorting hash buckets so entries can be found using a
  	  binary search, rather than a linear scan
  
*************** Cache Usage
*** 972,977 ****
--- 980,992 ----
    faster than a sequential scan it must avoid access to the heap
    to obtain tuple visibility information.
  
+ * Provide a way to calculate an "estimated COUNT(*)"
+ 
+   Perhaps by using the optimizer's cardinality estimates or random
+   sampling.
+ 
+   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 
*************** Locking
*** 1075,1080 ****
--- 1090,1098 ----
  
  * Fix priority ordering of read and write light-weight locks (Neil)
  
+   http://archives.postgresql.org/pgsql-hackers/2004-11/msg00893.php
+   http://archives.postgresql.org/pgsql-hackers/2004-11/msg00905.php
+ 
  
  Startup Time Improvements
  =========================
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to