diff --git a/doc/TODO b/doc/TODO index 3c4269e741..d8f55315cb 100644 --- a/doc/TODO +++ b/doc/TODO @@ -1,6 +1,6 @@ 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 --------------------------------------------------------------------------- diff --git a/doc/TODO.detail/inherit b/doc/TODO.detail/inherit index 3a4d1cc902..a80e0c77fc 100644 --- a/doc/TODO.detail/inherit +++ b/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 ; 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 ; 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 +cc: "Hiroshi Inoue" , "Peter Eisentraut" , + "PostgreSQL Development" +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 + 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 +Sender: owner-pgsql-hackers@postgreSQL.org +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 + +************ +