mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2024-11-27 07:21:09 +08:00
Code Issues Packages Projects Releases Wiki Activity

Update TODO list.

Browse Source
This commit is contained in:
Bruce Momjian 2000-01-28 03:46:06 +00:00
parent 552bd9645c
commit a85b67d05b
2 changed files with 85 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
doc/TODO
View File

@ -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
---------------------------------------------------------------------------

80
doc/TODO.detail/inherit
View File

@ -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
************