Update TODO list.
This commit is contained in:
Bruce Momjian
parent
552bd9645c
commit
a85b67d05b
14
doc/TODO
14
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
|
||||
|
||||
---------------------------------------------------------------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
************
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue