TODO list for PostgreSQL
========================
-Last updated: Thu Jan 27 22:38:49 EST 2000
+Last updated: Thu Jan 27 22:45:01 EST 2000
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)
* -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
* 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)
* 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
* -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
---------------------------------------------------------------------------
regards, tom lane
+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
; 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)
+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
; Mon, 24 Jan 2000 22:58:33 -0500 (EST)
+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
+cc: "Hiroshi Inoue"
, "Peter Eisentraut" ,
+ "PostgreSQL Development"
+Subject: Re: [HACKERS] Happy column dropping
+Comments: In-reply-to Don Baccus
+ message dated "Mon, 24 Jan 2000 18:41:37 -0800"
+Date: Mon, 24 Jan 2000 22:57:12 -0500
+From: Tom Lane
+Status: RO
+
+Don Baccus 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
+
+************
+