Update TODO list.

doc/TODO

 TODO list for PostgreSQL
 ========================
-Last updated:		Thu Jan 27 22:38:49 EST 2000
+Last updated:		Thu Jan 27 22:45:01 EST 2000
 
 Current maintainer:	Bruce Momjian (pgman@candle.pha.pa.us)
 
@@ -24,14 +24,11 @@ RESOURCES
 
 PARSER
 
-* Disallow inherited columns with the same name as new columns
 * -INSERT INTO ... SELECT with AS columns matching result columns problem
 * SELECT pg_class FROM pg_class generates strange error
 * Alter TABLE ADD COLUMN does not honor DEFAULT, add CONSTRAINT
-* Do not allow bpchar column creation without length
 * -Select a[1] FROM test fails, it needs test.a[1](Tom)
 * -Array index references without table name cause problems [array](Tom)
-* Update table SET table.value = 3 fails(SQL standard says this is OK)
 * Creating index of TIMESTAMP & RELTIME fails, or rename to DATETIME(Thomas)
 * SELECT foo UNION SELECT foo is incorrectly simplified to SELECT foo
 * -INSERT ... SELECT ... GROUP BY groups by target columns not source columns(Tom)
@@ -43,9 +40,8 @@ PARSER
 * -CREATE TABLE x AS SELECT 1 UNION SELECT 2 fails
 * -CREATE TABLE test(col char(2) DEFAULT user) fails in length restriction
 * -mismatched types in CREATE TABLE ... DEFAULT causes problems [default]
-* SELECT ... UNION ... ORDER BY fails when sort expr not in result list
+* -SELECT ... UNION ... ORDER BY fails when sort expr not in result list
 * Be smarter about promoting types when UNION merges different data types
-* SELECT ... UNION ... GROUP BY fails if column types disagree
 * redesign INSERT ... SELECT to have two levels of target list
 * -select * from pg_class where oid in (0,-1)
 * have INTERSECT/EXCEPT prevent duplicates unless ALL is specified
@@ -120,7 +116,7 @@ TYPES
 * Add IPv6 capability to INET/CIDR types
 * Make a separate SERIAL type?
 * Store binary-compatible type information in the system
-* Allow user to define char1 column
+* -Allow user to define char1 column
 * Add support for & operator
 * Allow LOCALE on a per-column basis, default to ASCII
 * -Allow LOCALE to use indexes in regular expression searches(Tom)
@@ -218,7 +214,7 @@ MISC
 * Missing optimizer selectivities for date, r-tree, etc. [optimizer]
 * -Overhaul mdmgr/smgr to fix double unlinking and double opens, cleanup
 * Overhaul bufmgr/lockmgr/transaction manager
-* Add PL/Perl(Mark Hollomon)
+* -Add PL/Perl(Mark Hollomon)
 * -Add option for postgres user have a password by default(Peter E)
 * Add configure test to check for C++ need for *.h and namespaces
 * Allow BLCKSZ <= 64k, not <= 32k
@@ -293,7 +289,7 @@ SOURCE CODE
 * -Make configure --enable-debug add -g on compile line
 * Does Mariposa source contain any other bug fixes?
 * Remove SET KSQO option if OR processing is improved(Tom)
-* Pre-generate lex and yacc output so not required for install
+* -Pre-generate lex and yacc output so not required for install
 
 ---------------------------------------------------------------------------
 

doc/TODO.detail/inherit

@@ -267,3 +267,83 @@ misleading success response code is not my idea of proper behavior.
 			regards, tom lane
 
 
+From owner-pgsql-hackers@hub.org Mon Jan 24 23:46:25 2000
+Received: from hub.org (hub.org [216.126.84.1])
+	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id XAA25453
+	for <pgman@candle.pha.pa.us>; Mon, 24 Jan 2000 23:46:24 -0500 (EST)
+Received: from localhost (majordom@localhost)
+	by hub.org (8.9.3/8.9.3) with SMTP id XAA81794;
+	Mon, 24 Jan 2000 23:01:22 -0500 (EST)
+	(envelope-from owner-pgsql-hackers)
+Received: by hub.org (bulk_mailer v1.5); Mon, 24 Jan 2000 22:59:46 -0500
+Received: (from majordom@localhost)
+	by hub.org (8.9.3/8.9.3) id WAA80721
+	for pgsql-hackers-outgoing; Mon, 24 Jan 2000 22:58:59 -0500 (EST)
+	(envelope-from owner-pgsql-hackers@postgreSQL.org)
+Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
+	by hub.org (8.9.3/8.9.3) with ESMTP id WAA80619
+	for <pgsql-hackers@postgreSQL.org>; Mon, 24 Jan 2000 22:58:33 -0500 (EST)
+	(envelope-from tgl@sss.pgh.pa.us)
+Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
+	by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id WAA11576;
+	Mon, 24 Jan 2000 22:57:12 -0500 (EST)
+To: Don Baccus <dhogaza@pacifier.com>
+cc: "Hiroshi Inoue" <Inoue@tpf.co.jp>, "Peter Eisentraut" <peter_e@gmx.net>,
+        "PostgreSQL Development" <pgsql-hackers@postgreSQL.org>
+Subject: Re: [HACKERS] Happy column dropping 
+In-reply-to: <3.0.1.32.20000124184137.01069490@mail.pacifier.com> 
+References: <001001bf66d7$b531ba00$2801007e@tpf.co.jp> <001001bf66d7$b531ba00$2801007e@tpf.co.jp> <3.0.1.32.20000124184137.01069490@mail.pacifier.com>
+Comments: In-reply-to Don Baccus <dhogaza@pacifier.com>
+	message dated "Mon, 24 Jan 2000 18:41:37 -0800"
+Date: Mon, 24 Jan 2000 22:57:12 -0500
+Message-ID: <11573.948772632@sss.pgh.pa.us>
+From: Tom Lane <tgl@sss.pgh.pa.us>
+Sender: owner-pgsql-hackers@postgreSQL.org
+Status: RO
+
+Don Baccus <dhogaza@pacifier.com> writes:
+> Just a reality check for my learning of the internals.  Out of curiousity
+> I coincidently have spent the last hour looking to see how add column's
+> implemented.  It doesn't appear to do anything other than the new attribute
+> to the proper system table.  heap_getattr() just returns null if you ask
+> for an attribute past the end of the tuple.  
+
+> This would appear to be (at least one reason) why you can't add a "not null"
+> constraint to a column you're adding to an existing relation, or set the
+> new column to some non-null default value.
+
+> Correct?  (again, to see if my eyeballs and brain are working in synch
+> tonight)
+
+Yup, that's about the size of it.  ADD COLUMN doesn't actually touch the
+table itself, so it can only add a column that's initially all NULLs.
+And even this depends on some uncomfortable assumptions about the
+robustness of heap_getattr().  I have always wondered whether it works
+if you ADD COLUMN a 33'rd column (or anything that is just past the
+next padding boundary for the null-values bitmap).
+
+Another problem with it is seen when you do a recursive ADD COLUMN in
+an inheritance tree.  The added column has the first free column number
+in each table, which generally means that it has different numbers in
+the children than in the parent.  There are some kluges to make this
+sort-of-work for simple cases, but a lot of stuff fails unpleasantly
+--- Chris Bitmead can show you some scars from that, IIRC.
+
+> Does your comment imply that it's planned to change this, i.e. actually
+> add the new column to each tuple in the relation rather than use the
+> existing, somewhat elegant hack?
+
+That's what I would like to see: all the children should have the
+same column numbers for all columns that they inherit from the parent.
+
+(Now, this would mean not only physically altering the tuples of
+the children, but also renumbering their added columns, which has
+implications on stored rules and triggers and so forth.  It'd be
+painful, no doubt about it.  Still, I'd rather pay the price in the
+seldom-used ADD COLUMN case than try to deal with out-of-sync column
+numbers in many other, more commonly exercised, code paths.)
+
+			regards, tom lane
+
+************
+