open-dsi
/
postgres
mirror of https://github.com/postgres/postgres
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
10027 Commits
38 Branches
669 Tags
768 MiB
Tag: Branch: Tree: 23c25ab36e
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '23c25ab36e'
${ noResults }
postgres/doc/TODO.detail/inheritance

767 lines
32 KiB
Raw Normal View History Unescape

Update TODO list.
27 years ago
From owner-pgsql-hackers@hub.org Tue Jun 1 22:31:18 1999
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id WAA09988
for <maillist@candle.pha.pa.us>; Tue, 1 Jun 1999 22:31:17 -0400 (EDT)
Update TODO list.
27 years ago
Received: from hub.org (hub.org [209.167.229.1]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id WAA18944 for <maillist@candle.pha.pa.us>; Tue, 1 Jun 1999 22:08:09 -0400 (EDT)
Update TODO list.
27 years ago
Received: from hub.org (hub.org [209.167.229.1])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA75604;
Tue, 1 Jun 1999 22:01:31 -0400 (EDT)
(envelope-from owner-pgsql-hackers@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Tue, 01 Jun 1999 22:01:11 +0000 (EDT)
Received: (from majordom@localhost)
by hub.org (8.9.3/8.9.3) id WAA75519
for pgsql-hackers-outgoing; Tue, 1 Jun 1999 22:01:09 -0400 (EDT)
(envelope-from owner-pgsql-hackers@postgreSQL.org)
X-Authentication-Warning: hub.org: majordom set sender to owner-pgsql-hackers@postgreSQL.org using -f
Received: from localhost.localdomain (h246.ozemail2.ozemail.com.au [203.108.14.246])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA75452
for <pgsql-hackers@hub.org>; Tue, 1 Jun 1999 22:00:50 -0400 (EDT)
(envelope-from chris.bitmead@bigfoot.com)
Received: from bigfoot.com (localhost [127.0.0.1])
by localhost.localdomain (8.8.7/8.8.7) with ESMTP id KAA04059
for <pgsql-hackers@hub.org>; Wed, 2 Jun 1999 10:50:11 +1000
Message-ID: <37547FC3.40106A5E@bigfoot.com>
Date: Wed, 02 Jun 1999 10:50:11 +1000
From: Chris Bitmead <chris.bitmead@bigfoot.com>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.6 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@hub.org
Subject: Re: [HACKERS] ALTER TABLE ADD COLUMN
References: <199906011436.KAA23479@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-pgsql-hackers@postgreSQL.org
Precedence: bulk
Status: RO
Bruce Momjian wrote:
> Our TODO now has:
>
> * ALTER TABLE ADD COLUMN to inherited table put column in wrong place
>
> I don't think any of us understand the issues on this one.
Let me guess at the problem. When you add a column, it doesn't change
all the records, therefore the column must be added at the end. This
means that the columns will not be in the same order as if you had
created them from scratch.
There seem to be three solutions:
a) Go to a much more sophisticated schema system, with versions and
version numbers (fairly hard but desirable to fix other schema change
problems). Then insert the column in the position it is supposed to be
in.
b) Fix the copy command to input and output the columns, not in the
order they are in, but in the order they would be in on re-creation.
c) make the copy command take arguments specifying the field names, like
INSERT can do.
I think it would be good if Postgres had all 3 features. Probably (b) is
the least work.
Update TODO list.
27 years ago
From owner-pgsql-general@hub.org Fri Jul 9 04:01:16 1999
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id EAA22565
for <maillist@candle.pha.pa.us>; Fri, 9 Jul 1999 04:01:15 -0400 (EDT)
Update TODO list.
27 years ago
Received: from hub.org (hub.org [209.167.229.1]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id DAA10238 for <maillist@candle.pha.pa.us>; Fri, 9 Jul 1999 03:56:46 -0400 (EDT)
Update TODO list.
27 years ago
Received: from hub.org (hub.org [209.167.229.1])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA79895;
Fri, 9 Jul 1999 03:53:13 -0400 (EDT)
(envelope-from owner-pgsql-general@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Fri, 09 Jul 1999 03:47:45 +0000 (EDT)
Received: (from majordom@localhost)
by hub.org (8.9.3/8.9.3) id DAA79076
for pgsql-general-outgoing; Fri, 9 Jul 1999 03:47:43 -0400 (EDT)
(envelope-from owner-pgsql-general@postgreSQL.org)
X-Authentication-Warning: hub.org: majordom set sender to owner-pgsql-general@postgreSQL.org using -f
Received: from ns.idianet.net ([195.154.201.1])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA79054
for <pgsql-general@postgreSQL.org>; Fri, 9 Jul 1999 03:47:37 -0400 (EDT)
(envelope-from haj@idianet.net)
Received: from kosovo (ppp150-paris2.isdnet.net [194.149.182.150])
by ns.idianet.net (8.9.1/8.9.1) with SMTP id JAA08143;
Fri, 9 Jul 1999 09:43:35 +0200 (CEST)
Message-ID: <000c01bec9df$3704bd20$0601a8c0@kosovo.idianet.net>
Reply-To: "Jonathan davis" <haj@idianet.net>
From: "Jonathan davis" <haj@idianet.net>
To: "Bruce Momjian" <maillist@candle.pha.pa.us>
Cc: "Pgsql-General@Postgresql. Org" <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] just little BUG
Date: Fri, 9 Jul 1999 09:46:42 +0200
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-pgsql-general@postgreSQL.org
Precedence: bulk
Status: ROr
>[Charset iso-8859-1 unsupported, filtering to ASCII...]
>> hello all
>>
>> normaly a UNIQUE PRIMARY KEY is unique but
>> when you use a heritage, you can insert a duplicate key !!!!
>
>I assume you mean inheritance.
>
>Can you send us a little test sample please?
>
>--
hello all
this is the problem:
example:
test=> CREATE TABLE MAN(name char(10) UNIQUE PRIMARY KEY);T
test=> CREATE TABLE PROFESSOR(scool char(20))INHERITS(MAN);
test=> INSERT INTO PROFESSOR(name) VALUES('DAVIS');
INSERT 54424 1
test=> INSERT INTO PROFESSOR(name) VALUES('DAVIS');
INSERT 54425 1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <HTML> <HEAD> <TITLE>PostgreSQL TODO list</TITLE> <BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#FF0000" VLINK="#A00000"\ ALINK="#0000FF"> <META NAME="generator" CONTENT="txt2html v1.25"> </HEAD> <BODY> <H1><A NAME="section-1">TODO list for PostgreSQL</A></H1> Last updated: Tue Sep 28 00:34:21 EDT 1999 <P> Current maintainer: Bruce Momjian (<A HREF="mailto:maillist@candle.pha.pa.us">maillist@candle.pha.pa.us</A>) <P> The most recent version of this document can be viewed at<BR> the PostgreSQL web site, <A HREF="http://www.PostgreSQL.org">http://www.PostgreSQL.org</A>. <P> A dash(-) marks changes that will appear in the next release. <P> Names in brackets "[<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/"></A>]" indicate more detailed information is available in<BR> the directory pgsql/doc/TODO.detail/ under that name. <H2><A NAME="section-1.1">RELIABILITY</A></H2> <P> <STRONG>RESOURCES</STRONG> <UL> <LI> Elog() does not free all its memory(Jan) <LI> spinlock stuck problem when elog(FATAL) and elog(ERROR) inside bufmgr <LI> Recover or force failure when disk space is exhausted </UL> <P> <STRONG>PARSER</STRONG> <UL> <LI> Disallow inherited columns with the same name as new columns <LI> INSERT INTO ... SELECT with AS columns matching result columns problem <LI> SELECT pg<U>class FROM pg</U>class generates strange error <LI> Alter TABLE ADD COLUMN does not honor DEFAULT, add CONSTRAINT <LI> Do not allow bpchar column creation without length <LI> -Select a[<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/1">1</A>] FROM test fails, it needs test.a[<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/1">1</A>] <LI> -Array index references without table name cause problems [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/array">array</A>] <LI> Update table SET table.value = 3 fails(SQL standard says this is OK) <LI> Creating index of TIMESTAMP &amp; RELTIME fails, or rename to DATETIME(Thomas) <LI> SELECT foo UNION SELECT foo is incorrectly simplified to SELECT foo <LI> -INSERT ... SELECT ... GROUP BY groups by target columns not source columns <LI> -CREATE TABLE test (a char(5) DEFAULT text '', b int4) fails on INSERT <LI> UNION with LIMIT fails <LI> Unique index on base column not honored on inserts from inherited table INSERT INTO inherit_table (unique<U>index</U>col) VALUES (dup) should fail [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/inherit">inherit</A>] <LI> CREATE TABLE x AS SELECT 1 UNION SELECT 2 fails <LI> CREATE TABLE test(col char(2) DEFAULT user) fails in length restriction <LI> mismatched types in CREATE TABLE ... DEFAULT causes problems [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/default">default</A>] <LI> SELECT ... UNION ... ORDER BY fails when sort expr not in result list <LI> Be smarter about promoting types when UNION merges different data types <LI> SELECT ... UNION ... GROUP BY fails if column types disagree <LI> redesign INSERT ... SELECT to have two levels of target list <LI> -select * from pg_class where oid in (0,-1) <LI> have INTERSECT/EXCEPT prevent duplicates unless ALL is specified <LI> prevent primary key of nine columns [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/primary">primary</A>] <LI> SELECT COUNT('asdf') FROM pg_class WHERE oid=12 crashes <LI> SELECT DISTINCT ON col1 col1 col2 FROM tab1 is broken [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/distinct">distinct</A>] <LI> -When using aggregates + GROUP BY, no rows in should yield no rows out </UL> <P> <STRONG>VIEWS</STRONG> <UL> <LI> Views containing aggregates sometimes fail(Jan) <LI> Views with spaces in view name fail when referenced <LI> Creating view and inheriting the view causes view* to show duplicates(inherit) </UL> <P> <STRONG>MISC</STRONG> <UL> <LI> User who can create databases can modify pg_database table <LI> Plpgsql does not handle quoted mixed-case identifiers <LI> Fix btree to give a useful elog when key &gt; 1/2 (page - overhead) <LI> pg_dump should preserve primary key information <LI> plpgsql regression tests fail on BSD/OS </UL> <H2><A NAME="section-1.2">ENHANCEMENTS</A></H2> <P> <STRONG>URGENT</STRONG> <UL> <LI> Add referential integrity(Jan?)[<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/primary">primary</A>] <LI> Add OUTER joins, left and right[<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/outer">outer</A>](Thomas, Bruce) <LI> Allow long tuples by chaining or auto-storing outside db (chaining,large objs) <LI> Eliminate limits on query length <LI> Fix memory leak for expressions?[<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/memory">memory</A>](Tom?) <LI> -Fix memory leak for aggregates? </UL> <P> <STRONG>ADMIN</STRONG> <UL> <LI> Better interface for adding to pg_group <LI> More access control over who can create tables and access the database <LI> Test syslog functionality <LI> Allow elog() to return error codes, not just messages <LI> Allow international error message support and add error codes <LI> Generate postmaster pid file and remove flock/fcntl lock code [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/flock">flock</A>] <LI> Add ability to specifiy location of lock/socket files [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/flock">flock</A>] </UL> <P> <STRONG>TYPES</STRONG> <UL> <LI> Add BIT, BIT VARYING <LI> Nchar (as distinguished from ordinary varchar), <LI> Domain capability <LI> Add STDDEV/VARIANCE() function for standard deviation computation/variance <LI> Allow compression of large fields or a compressed field type <LI> Large objects <UL> <LI> Fix large object mapping scheme, own typeid or reltype(Peter) <LI> Allow large text type to use large objects(Peter) <LI> Not to stuff everything as files in a single directory, hash dirs <LI> Allow large object vacuuming <LI> Tables that start with xinv confused to be large objects </UL> <LI> Allow pg_descriptions when creating types, tables, columns, and functions <LI> Add IPv6 capability to INET/CIDR types <LI> Make a separate SERIAL type? <LI> Store binary-compatible type information in the system <LI> Allow user to define char1 column <LI> Add support for &amp; operator <LI> Allow LOCALE on a per-column basis, default to ASCII <LI> Allow array on int8[<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/"></A>] <LI> Allow nulls in arrays <LI> Allow arrays to be ORDER'ed <LI> Remove Money type, add money formatting for decimal type <LI> Declare typein/out functions in pg_proc with a special "C string" data type <LI> Add non-large-object binary field <LI> Add index on NUMERIC/DECIMAL type <LI> Make Absolutetime/Relativetime int4 because time_t can be int8 on some ports <LI> Functions returning sets don't really work right[<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/function">function</A>] </UL> <P> <STRONG>VIEWS</STRONG> <UL> <LI> Allow DISTINCT on views <LI> Allow views of aggregate columns <LI> Allow views with subselects </UL> <P> <STRONG>INDEXES</STRONG> <UL> <LI> Allow CREATE INDEX zman_index ON test (date_trunc( 'day', zman ) datetime_ops) fails index can't store constant parameters <LI> Allow creation of functional indexes to use default types <LI> Permissions on indexes - prevent them? <LI> Allow SQL function indexes <LI> Add FILLFACTOR to index creation <LI> Allow indexing of LIKE with localle character sets <LI> Allow indexing of more than eight columns </UL> <P> <STRONG>COMMANDS</STRONG> <UL> <LI> ALTER TABLE ADD COLUMN to inherited table put column in wrong place [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/inherit">inherit</A>] <LI> Add ALTER TABLE DROP/ALTER COLUMN feature <LI> Allow CLUSTER on all tables at once, and improve CLUSTER, loses NOT <P> NULL specification on table [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/cluster">cluster</A>] <LI> Add SIMILAR TO to allow character classes, 'pg_[<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/a-c">a-c</A>]%' <LI> Auto-destroy sequence on DROP of table with SERIAL(Ryan) <LI> Allow LOCK TABLE tab1, tab2, tab3 so all tables locked in unison <LI> Allow INSERT/UPDATE of system-generated oid value for a row <LI> Allow ESCAPE '\' at the end of LIKE for ANSI compliance [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/like">like</A>] <LI> Rewrite the LIKE handling by rewriting the user string with the supplied ESCAPE [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/like">like</A>] <LI> -Move LIKE index optimization handling to the optimizer <LI> Allow RULE recompilation <LI> Support UNION/INTERSECT/EXCEPT in sub-selects <LI> Allow DELETE and UPDATE to use inheritance using tablename* </UL> <P> <STRONG>CLIENTS</STRONG> <UL> <LI> Make NULL's come out at the beginning or end depending on the ORDER BY direction <LI> Allow flag to control COPY input/output of NULLs <LI> Update reltuples from COPY command <LI> Allow psql \copy to allow delimiters <LI> Add a function to return the last inserted oid, for use in psql scripts <LI> Allow psql to print nulls as distinct from "" [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/null">null</A>] </UL> <P> <STRONG>EXOTIC FEATURES</STRONG> <UL> <LI> Add sql3 recursive unions <LI> Add the concept of dataspaces <LI> Add replication of distributed databases <LI> Allow queries across multiple databases </UL> <P> <STRONG>MISC</STRONG> <UL> <LI> Increase identifier length(NAMEDATALEN) if small performance hit <LI> Allow row re-use without vacuum(Vadim) <LI> Create a background process for each database that runs while database is idle, finding superceeded rows, gathering stats and vacuuming <LI> Add UNIQUE capability to non-btree indexes <LI> -Certain indexes will not shrink, i.e. oid indexes with many inserts <LI> Restore unused oid's on backend exit if no one else has gotten oids <LI> Have UPDATE/DELETE clean out indexes <LI> Allow WHERE restriction on ctid <LI> Allow cursors to be DECLAREd/OPENed/CLOSEed outside transactions <LI> Allow PQrequestCancel() to terminate when in waiting-for-lock state <LI> -Transaction log, so re-do log can be on a separate disk by with after-row images(Vadim) [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/logging">logging</A>] <LI> Populate backend status area and write program to dump status data <LI> Make oid use unsigned int more reliably, pg_atoi() <LI> Allow subqueries in target list <LI> Put sort files, large objects in their own directory <LI> Do autocommit so always in a transaction block(?) <LI> Show location of syntax error in query [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/yacc">yacc</A>] <LI> Redesign the function call interface to handle NULLs better [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/function">function</A>] <LI> Document/trigger/rule so changes to pg<U>shadow recreate pg</U>pwd [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/pg_shadow">pg_shadow</A>] <LI> Missing optimizer selectivities for date, r-tree, etc. [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/optimizer">optimizer</A>] <LI> Overhaul mdmgr/smgr to fix double unlinking and double opens, cleanup <LI> Overhaul bufmgr/lockmgr/transaction manager <LI> Add PL/Perl(Mark Hollomon) <LI> Make postgres user have a password by default <LI> Add configure test to check for C++ need for *.h and namespaces <LI> Allow BLCKSZ &lt;= 64k, not &lt;= 32k <LI> redesign UNION structures to have separarate target lists <LI> Allow multi-level query trees for INSERT INTO ... SELECT </UL> <H2><A NAME="section-1.3">PERFORMANCE</A></H2> <P> <STRONG>FSYNC</STRONG> <UL> <LI> -Allow transaction commits with rollback with no-fsync performance [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/fsync">fsync</A>] <LI> -Prevent fsync in SELECT-only queries </UL> <P> <STRONG>INDEXES</STRONG> <UL> <LI> Use indexes in ORDER BY for restrictive data sets, min(), max() <LI> Pull requested data directly from indexes, bypassing heap data <LI> Use index to restrict rows returned by multi-key index when used with non-consecutive keys or OR clauses, so fewer heap accesses <LI> -Convert function(constant) into a constant for index use <LI> Allow LIMIT ability on single-table queries that have no ORDER BY to use a matching index [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/limit">limit</A>] <LI> Improve LIMIT processing by using index to limit rows processed [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/limit">limit</A>] <LI> Have optimizer take LIMIT into account when considering index scans [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/limit">limit</A>] <LI> Make index creation use psort code, because it is now faster(Vadim) <LI> Allow creation of sort temp tables &gt; 1 Gig <LI> Create more system table indexes for faster cache lookups <LI> fix indexscan() so it does leak memory by not requiring caller to free <LI> Improve <U>bt</U>binsrch() to handle equal keys better, remove <U>bt</U>firsteq()(Tom) <LI> Allow SELECT * FROM tab WHERE int2col = 4 use int2col index, int8, float4, numeric/decimal too [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/optimizer">optimizer</A>] <LI> -Allow optimizer to prefer plans that match ORDER BY </UL> <P> <STRONG>CACHE</STRONG> <UL> <LI> Cache most recent query plan(s) [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/prepare">prepare</A>] <LI> Shared catalog cache, reduce lseek()'s by caching table size in shared area <LI> elog() flushes cache, try invalidating just entries from current xact, perhaps using invalidation cache </UL> <P> <STRONG>MISC</STRONG> <UL> <LI> Allow compression of log and meta data <LI> Allow char() not to use variable-sized header to reduce disk size <LI> Do async I/O to do better read-ahead of data <LI> -Fix memory exhaustion when using many OR's [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/cnfify">cnfify</A>] <LI> Get faster regex() code from Henry Spencer &lt;<A HREF="mailto:henry@zoo.utoronto.ca">henry@zoo.utoronto.ca</A>&gt; when it is available <LI> Use mmap() rather than SYSV shared memory(?) <LI> -Process const = const parts of OR clause in separate pass <LI> Make oid use oidin/oidout not int4in/int4out in pg_type.h <LI> Improve Subplan list handling <LI> Allow Subplans to use efficient joins(hash, merge) with upper variable [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/subquery">subquery</A>] <LI> use fmgr_info()/fmgr_faddr() instead of fmgr() calls in high-traffic places, like GROUP BY, UNIQUE, index processing, etc. <LI> improve dynamic memory allocation by introducing tuple-context memory allocation [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/memory">memory</A>] <LI> fix memory leak in cache code when non-existant table is referenced <LI> In WHERE tab1.x=3 AND tab1.x=tab2.y, add tab2.y=3 <LI> pass atttypmod through parser in more cases [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/atttypmod">atttypmod</A>] <LI> remove duplicate type in/out functions for disk and net <LI> Allow persistent backends [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/persistent">persistent</A>] <LI> Misc [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/performance">performance</A>] </UL> <H2><A NAME="section-1.4">SOURCE CODE</A></H2> <UL> <LI> Add use of 'const' for varibles in source tree <LI> Fix C optimizer problem where fmgr_ptr calls return different types [<A HREF="http://www.postgresql.org/docs/pgsql/doc/TODO.detail/alpha">alpha</A>] <LI> -Add needed includes and removed unneeded include files(Bruce) <LI> Make configure --enable-debug add -g on compile line <LI> Does Mariposa source contain any other bug fixes? <LI> Remove SET KSQO option if OR processing is improved(Tom) </UL> <HR> <H3><A NAME="section-1.4.1">Developers who have claimed items are:</A></H3> <UL> <LI> Billy is Billy G. Allie &lt;<A HREF="mailto:Bill.Allie@mug.org">Bill.Allie@mug.org</A>&gt; <LI> Brook is Brook Milligan &lt;<A HREF="mailto:brook@trillium.NMSU.Edu">brook@trillium.NMSU.Edu</A>&gt; <LI> Bruce is Bruce Momjian&lt;<A HREF="mailto:maillist@candle.pha.pa.us">maillist@candle.pha.pa.us</A>&gt; <LI> Bryan is Bryan Henderson&lt;<A HREF="mailto:bryanh@giraffe.netgate.net">bryanh@giraffe.netgate.net</A>&gt; <LI> D'Arcy is D'Arcy J.M. Cain &lt;<A HREF="mailto:darcy@druid.net">darcy@druid.net</A>&gt; <LI> David is David Hartwig &lt;<A HREF="mailto:daveh@insightdist.com">daveh@insightdist.com</A>&gt; <LI> Edmund is Edmund Mergl &lt;<A HREF="mailto:E.Mergl@bawue.de">E.Mergl@bawue.de</A>&gt; <LI> Goran is Goran Thyni &lt;<A HREF="mailto:goran@kyla.kiruna.se">goran@kyla.kiruna.se</A>&gt; <LI> Hiroshi is Hiroshi Inoue&lt;<A HREF="mailto:Inoue@tpf.co.jp">Inoue@tpf.co.jp</A>&gt; <LI> Jan is Jan Wieck &lt;<A HREF="mailto:wieck@sapserv.debis.de">wieck@sapserv.debis.de</A>&gt; <LI> Marc is Marc Fournier &lt;<A HREF="mailto:scrappy@hub.org">scrappy@hub.org</A>&gt; <LI> Massimo Dal Zotto &lt;<A HREF="mailto:dz@cs.unitn.it">dz@cs.unitn.it</A>&gt; <LI> Michael is Michael Meskes &lt;<A HREF="mailto:meskes@postgresql.org">meskes@postgresql.org</A>&gt; <LI> Oleg is Oleg Bartunov &lt;<A HREF="mailto:oleg@sai.msu.su">oleg@sai.msu.su</A>&gt; <LI> Peter is Peter T Mount &lt;<A HREF="mailto:peter@retep.org.uk">peter@retep.org.uk</A>&gt; <LI> Ryan is Ryan Bradetich &lt;<A HREF="mailto:rbrad@hpb50023.boi.hp.com">rbrad@hpb50023.boi.hp.com</A>&gt; <LI> Stefan Simkovics &lt;<A HREF="mailto:ssimkovi@rainbow.studorg.tuwien.ac.at">ssimkovi@rainbow.studorg.tuwien.ac.at</A>&gt; <LI> Tatsuo is Tatsuo Ishii &lt;<A HREF="mailto:t-ishii@sra.co.jp">t-ishii@sra.co.jp</A>&gt; <LI> Tom is Tom Lane &lt;<A HREF="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</A>&gt; <LI> Thomas is Thomas Lockhart &lt;<A HREF="mailto:lockhart@alumni.caltech.edu">lockhart@alumni.caltech.edu</A>&gt; <LI> TomH is Tom I Helbekkmo &lt;<A HREF="mailto:tih@Hamartun.Priv.NO">tih@Hamartun.Priv.NO</A>&gt; <LI> Vadim is "Vadim B. Mikheev" &lt;<A HREF="mailto:vadim@krs.ru">vadim@krs.ru</A>&gt; </UL> </BODY> </HTML>
27 years ago
From owner-pgsql-hackers@hub.org Tue Apr 20 10:34:34 1999
Received: from hub.org (hub.org [209.47.145.100])
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id KAA28480
for <maillist@candle.pha.pa.us>; Tue, 20 Apr 1999 10:34:31 -0400 (EDT)
Received: from localhost (majordom@localhost)
by hub.org (8.9.3/8.9.1) with SMTP id KAA12281;
Tue, 20 Apr 1999 10:33:22 -0400 (EDT)
(envelope-from owner-pgsql-hackers@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Tue, 20 Apr 1999 10:32:04 +0000 (EDT)
Received: (from majordom@localhost)
by hub.org (8.9.3/8.9.1) id KAA11432
for pgsql-hackers-outgoing; Tue, 20 Apr 1999 10:32:01 -0400 (EDT)
(envelope-from owner-pgsql-hackers@postgreSQL.org)
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net [139.130.75.122])
by hub.org (8.9.3/8.9.1) with ESMTP id KAA11378
for <hackers@postgreSQL.org>; Tue, 20 Apr 1999 10:31:52 -0400 (EDT)
(envelope-from chris.bitmead@bigfoot.com)
Received: from bigfoot.com (chris@localhost [127.0.0.1])
by tech.com.au (8.8.7/8.8.7) with ESMTP id AAA21255
for <hackers@postgreSQL.org>; Wed, 21 Apr 1999 00:31:32 +1000
Message-ID: <371C8FC3.4804CF87@bigfoot.com>
Date: Tue, 20 Apr 1999 14:31:31 +0000
From: Chris Bitmead <chris.bitmead@bigfoot.com>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: hackers@postgreSQL.org
Subject: Re: [HACKERS] Heads up: does RULES regress test still work for you?
References: <199904151054.UAA07367@tech.com.au> <3715C69E.AE517ADB@bigfoot.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-pgsql-hackers@postgreSQL.org
Precedence: bulk
Status: RO
Does the following indicate a bug? It sure is wierd. Maybe some of these
statements aren't supported by postgresql (??), but the outcome doesn't
make sense to me.
httpd=> CREATE TABLE x (y text);
CREATE
httpd=> CREATE VIEW z AS select * from x;
CREATE
httpd=> CREATE TABLE a (b text) INHERITS(z);
CREATE
httpd=> INSERT INTO x VALUES ('foo');
INSERT 168602 1
httpd=> select * from z*;
y
---
foo
foo
(2 rows)
How did we suddenly get two rows??
--
Chris Bitmead
http://www.bigfoot.com/~chris.bitmead
mailto:chris.bitmead@bigfoot.com
From owner-pgsql-hackers@hub.org Tue May 25 11:01:16 1999
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id LAA15867
for <maillist@candle.pha.pa.us>; Tue, 25 May 1999 11:01:16 -0400 (EDT)
Received: from hub.org (hub.org [209.167.229.1]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id KAA10712 for <maillist@candle.pha.pa.us>; Tue, 25 May 1999 10:55:17 -0400 (EDT)
Received: from hub.org (hub.org [209.167.229.1])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA07206;
Tue, 25 May 1999 10:45:50 -0400 (EDT)
(envelope-from owner-pgsql-hackers@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Tue, 25 May 1999 10:43:02 +0000 (EDT)
Received: (from majordom@localhost)
by hub.org (8.9.3/8.9.3) id KAA06706
for pgsql-hackers-outgoing; Tue, 25 May 1999 10:43:01 -0400 (EDT)
(envelope-from owner-pgsql-hackers@postgreSQL.org)
X-Authentication-Warning: hub.org: majordom set sender to owner-pgsql-hackers@postgreSQL.org using -f
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA06690
for <pgsql-hackers@postgreSQL.org>; Tue, 25 May 1999 10:42:57 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA02984
for <pgsql-hackers@postgreSQL.org>; Tue, 25 May 1999 10:42:39 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: [HACKERS] INSERT INTO view means what exactly?
Date: Tue, 25 May 1999 10:42:39 -0400
Message-ID: <2981.927643359@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Sender: owner-pgsql-hackers@postgreSQL.org
Precedence: bulk
Status: ROr
With current sources:
regression=> CREATE TABLE x (y text);
CREATE
regression=> CREATE VIEW z AS select * from x;
CREATE
regression=> INSERT INTO x VALUES ('foo');
INSERT 411635 1
regression=> INSERT INTO z VALUES ('bar');
INSERT 411636 1
regression=> select * from x;
y
---
foo
(1 row)
regression=> select * from z;
y
---
foo
(1 row)
OK, where'd tuple 411636 go? Seems to me that the insert should either
have been rejected or caused an insert into x, depending on how
transparent you think views are (I always thought they were
read-only?). Dropping the data into never-never land and giving a
misleading success response code is not my idea of proper behavior.
regards, tom lane
Update TODO list.
26 years ago
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
************
Fix ODBC for new binary fopen/open params
26 years ago
From owner-pgsql-hackers@hub.org Tue Jan 25 18:34:14 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 TAA04935
for <pgman@candle.pha.pa.us>; Tue, 25 Jan 2000 19:34:13 -0500 (EST)
Received: from localhost (majordom@localhost)
by hub.org (8.9.3/8.9.3) with SMTP id TAA31870;
Tue, 25 Jan 2000 19:22:44 -0500 (EST)
(envelope-from owner-pgsql-hackers)
Received: by hub.org (bulk_mailer v1.5); Tue, 25 Jan 2000 19:21:06 -0500
Received: (from majordom@localhost)
by hub.org (8.9.3/8.9.3) id TAA31364
for pgsql-hackers-outgoing; Tue, 25 Jan 2000 19:20:07 -0500 (EST)
(envelope-from owner-pgsql-hackers@postgreSQL.org)
Received: from hu.tm.ee (ppp809.tele2.ee [212.107.37.109])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA31158
for <pgsql-hackers@postgreSQL.org>; Tue, 25 Jan 2000 19:19:04 -0500 (EST)
(envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1])
by hu.tm.ee (Postfix) with ESMTP
id 46B6213469; Wed, 26 Jan 2000 02:25:13 +0200 (EET)
Message-ID: <388E3EE9.46880647@tm.ee>
Date: Wed, 26 Jan 2000 02:25:13 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: Happy column adding (was RE: [HACKERS] Happy columndropping)
References: <3.0.1.32.20000125113001.00f8acb0@mail.pacifier.com>
<20000125114453.E423@rice.edu>
<001401bf6704$5ca7e3a0$2801007e@tpf.co.jp>
<Pine.GSO.4.02A.10001251152160.11899-100000@Val.DoCS.UU.SE>
<3.0.1.32.20000125080125.00f7f160@mail.pacifier.com>
<20000125114453.E423@rice.edu>
<3.0.1.32.20000125113001.00f8acb0@mail.pacifier.com> <3.0.1.32.20000125151022.00f8c4c0@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-pgsql-hackers@postgreSQL.org
Status: OR
Don Baccus wrote:
>
> Ahhh...yes. I haven't looked at the inheritance code, yet, but I see
> what you're saying. I think. Do child-table columns follow parent-table
> columns by some chance (in today's absolute column number scheme)?
>
> >If we were willing to hardwire the assumption that DROP COLUMN never
> >physically drops a column, but only hides it and adjusts logical column
> >numbers, then the physical column numbers could serve as permanent IDs;
> >so we'd only need two numbers not three. This might be good, or not.
>
> Yes. But if I'm right about how child-table columns are numbered,
> wouldn't add column still cause a problem, i.e. you'd still have to
> change their physical column number?
If we allow deleted column as a basic feature of postgres,
it could be like that
base: COL1 | COL2 | COL3
child: COL1 | COL2 | COL3 | COL4
after add column 5 to base table
base: COL1 | COL2 | COL3 | del4 | COL5
child: COL1 | COL2 | COL3 | COL4 | COL5
after add column 6 to child
base: COL1 | COL2 | COL3 | del4 | COL5
child: COL1 | COL2 | COL3 | COL4 | COL5 | COL6
after drop column 2 from base table
base: COL1 | del2 | COL3 | del4 | COL5
child: COL1 | del2 | COL3 | COL4 | COL5 | COL6
dropping column from child table that is not a deleted column in
parent is not allowed.
The delN columns are always NULLed on reading tuple and are written as proper
null columns (taking up space only in NULL bitmask)
multiple inheritance is tricky and _requires_ unique column ids maybe oids
from pg_attribute to be doable.
-----------------
Hannu
************
From owner-pgsql-hackers@hub.org Thu Jan 27 11:48:26 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 MAA25953
for <pgman@candle.pha.pa.us>; Thu, 27 Jan 2000 12:48:25 -0500 (EST)
Received: from localhost (majordom@localhost)
by hub.org (8.9.3/8.9.3) with SMTP id MAA22723;
Thu, 27 Jan 2000 12:39:27 -0500 (EST)
(envelope-from owner-pgsql-hackers)
Received: by hub.org (bulk_mailer v1.5); Thu, 27 Jan 2000 12:36:16 -0500
Received: (from majordom@localhost)
by hub.org (8.9.3/8.9.3) id MAA22021
for pgsql-hackers-outgoing; Thu, 27 Jan 2000 12:35:23 -0500 (EST)
(envelope-from owner-pgsql-hackers@postgreSQL.org)
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA21886
for <pgsql-hackers@postgresql.org>; Thu, 27 Jan 2000 12:34:47 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61911 "EHLO regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S294955AbQA0ReG>;
Thu, 27 Jan 2000 18:34:06 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12DsvR-0000HH-00; Thu, 27 Jan 2000 18:41:45 +0100
Date: Thu, 27 Jan 2000 18:41:45 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Column ADDing issues
In-Reply-To: <15550.948845404@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0001262020480.416-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: owner-pgsql-hackers@postgreSQL.org
Status: ORr
On 2000-01-25, Tom Lane mentioned:
> > Everything has its order and it's not like the inheritance as such is
> > broken.
>
> Yes, a whole bunch of stuff is broken after this happens. Go back and
> consult the archives --- or maybe Chris Bitmead will fill you in; he's
> got plenty of scars to show for this set of problems. (All I recall
> offhand is that pg_dump and reload can fail to generate a working
> database.) The bottom line is that it would be a lot nicer if column c
> had the same column position in both the parent table and the child
> table(s).
This should be fixed in pg_dump by infering something via the oids of the
pg_attribute entries. No need to mess up the backend for it.
Maybe pg_dump should optionally dump schemas in terms of insert into
pg_something commands rather than actual DDL. ;)
>
> I suggest you be very cautious about messing with ALTER TABLE until you
> understand why inheritance makes it such a headache ;-)
I'm just trying to get the defaults and constraints working. If
inheritance stays broken the way it previously was, it's beyond my
powers. But I get the feeling that people rather not alter their tables
unless they have *perfect* alter table commands. I don't feel like arguing
with them, they'll just have to do without then.
--
Peter Eisentraut Sernanders v<EFBFBD>g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
************
Change Copyright from PostgreSQL, Inc to PostgreSQL Global Development Group.
25 years ago
From pgsql-general-owner+M2136@hub.org Sat Jun 3 23:31:02 2000
Received: from renoir.op.net (root@renoir.op.net [207.29.195.4])
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id WAA28683
for <pgman@candle.pha.pa.us>; Sat, 3 Jun 2000 22:31:01 -0400 (EDT)
Add to inheritance
25 years ago
Received: from news.tht.net (news.hub.org [216.126.91.242]) by renoir.op.net (o1/$Revision: 1.1 $) with ESMTP id WAA20977 for <pgman@candle.pha.pa.us>; Sat, 3 Jun 2000 22:05:07 -0400 (EDT)
Change Copyright from PostgreSQL, Inc to PostgreSQL Global Development Group.
25 years ago
Received: from hub.org (majordom@hub.org [216.126.84.1])
by news.tht.net (8.9.3/8.9.3) with ESMTP id VAD35811;
Sat, 3 Jun 2000 21:54:36 -0400 (EDT)
(envelope-from pgsql-general-owner+M2136@hub.org)
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA12118
for <pgsql-general@postgresql.org>; Sat, 3 Jun 2000 21:41:27 -0400 (EDT)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.student.UU.SE ([130.238.5.2]:61160 "EHLO
regulus.its.uu.se") by merganser.its.uu.se with ESMTP
id <S168006AbQFDBlC>; Sun, 4 Jun 2000 03:41:02 +0200
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12yPV7-0002Tp-00; Sun, 04 Jun 2000 03:46:53 +0200
Date: Sun, 4 Jun 2000 03:46:53 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: ldm@apartia.com
cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] child table doesn't inherit PRIMARY KEY?
In-Reply-To: <20000603172256.A3435@styx>
Message-ID: <Pine.LNX.4.21.0006040341030.348-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
X-Mailing-List: pgsql-general@postgresql.org
Precedence: bulk
Sender: pgsql-general-owner@hub.org
Status: ORr
Louis-David Mitterrand writes:
> When creating a child (through CREATE TABLE ... INHERIT (parent)) it
> seems the child gets all of the parent's contraints _except_ its PRIMARY
> KEY. Is this normal?
It's kind of a bug.
--
Peter Eisentraut Sernanders v<EFBFBD>g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From sszabo@megazone23.bigpanda.com Fri Jan 19 12:37:34 2001
Received: from megazone23.bigpanda.com (rfx-64-6-210-138.users.reflexcom.com [64.6.210.138])
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id MAA28247
for <pgman@candle.pha.pa.us>; Fri, 19 Jan 2001 12:37:33 -0500 (EST)
Received: from localhost (sszabo@localhost)
by megazone23.bigpanda.com (8.11.1/8.11.1) with ESMTP id f0JHb2H05566;
Fri, 19 Jan 2001 09:37:03 -0800 (PST)
Date: Fri, 19 Jan 2001 09:37:02 -0800 (PST)
From: Stephan Szabo <sszabo@megazone23.bigpanda.com>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] child table doesn't inherit PRIMARY KEY?
In-Reply-To: <200101190457.XAA13895@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0101190932480.5520-100000@megazone23.bigpanda.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: OR
Probably, since I see it in near recent sources (and it affects
UNIQUE as well. As I remember it, the last discussion on this couldn't
determine what the correct behavior for unique/primary key constraints
was in the inheritance case (is it a single unique hierarchy through
all the tables [would be needed for fk to inheritance trees] or
separate unique constraints for each table [which would be similar
to how many people seem to currently use postgres inheritance as a
shortcut]).
On Thu, 18 Jan 2001, Bruce Momjian wrote:
> Does this bug still exist?
>
> [ Charset ISO-8859-1 unsupported, converting... ]
> > Louis-David Mitterrand writes:
> >
> > > When creating a child (through CREATE TABLE ... INHERIT (parent)) it
> > > seems the child gets all of the parent's contraints _except_ its PRIMARY
> > > KEY. Is this normal?
From sszabo@megazone23.bigpanda.com Wed Jan 24 14:26:12 2001
Received: from megazone23.bigpanda.com (rfx-64-6-210-138.users.reflexcom.com [64.6.210.138])
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id OAA26091
for <pgman@candle.pha.pa.us>; Wed, 24 Jan 2001 14:26:10 -0500 (EST)
Received: from localhost (sszabo@localhost)
by megazone23.bigpanda.com (8.11.1/8.11.1) with ESMTP id f0OJPZ858086;
Wed, 24 Jan 2001 11:25:35 -0800 (PST)
Date: Wed, 24 Jan 2001 11:25:35 -0800 (PST)
From: Stephan Szabo <sszabo@megazone23.bigpanda.com>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [GENERAL] child table doesn't inherit PRIMARY KEY?
In-Reply-To: <200101241344.IAA12094@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0101241120310.57849-100000@megazone23.bigpanda.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: ORr
On Wed, 24 Jan 2001, Bruce Momjian wrote:
>
> OK, what do people want to do with this item? Add to TODO list?
>
> Seems making a separat unique constraint would be easy to do and be of
> value to most users.
The problem is that doing that will pretty much guarantee that we won't
be doing foreign keys to inheritance trees without changing that behavior
and we've seen people asking about adding that too. I think that this
falls into the general category of "Make inheritance make sense" (Now
there's a todo item :) ) Seriously, I think the work on how inheritance
is going to work will decide this, maybe we end up with a real inheritance
tree system and something that works like the current stuff in which case
I'd say it's probably one unique for the former and one per for the
latter.
Add to inheritance
25 years ago
From olly@lfix.co.uk Wed Jan 24 16:41:45 2001
Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89])
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id QAA05688
for <pgman@candle.pha.pa.us>; Wed, 24 Jan 2001 16:41:44 -0500 (EST)
Received: from lfix.demon.co.uk ([158.152.59.127] helo=linda.lfix.co.uk)
by anchor-post-31.mail.demon.net with esmtp (Exim 2.12 #1)
id 14LXfg-0007lc-0V; Wed, 24 Jan 2001 21:41:40 +0000
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.11.2/8.11.2/Debian 8.11.2-1) with ESMTP id f0OLfdF12876;
Wed, 24 Jan 2001 21:41:39 GMT
Message-Id: <200101242141.f0OLfdF12876@linda.lfix.co.uk>
X-Mailer: exmh version 2.2 06/23/2000 (debian 2.2-1) with nmh-1.0.4+dev
X-URL: http://www.lfix.co.uk/oliver
X-face: "xUFVDj+ZJtL_IbURmI}!~xAyPC"Mrk=MkAm&tPQnNq(FWxv49R}\>0oI8VM?O2VY+N7@F-
KMLl*!h}B)u@TW|B}6<X<J|}QsVlTi:RA:O7Abc(@D2Y/"J\S,b1!<&<B/J}b.Ii9@B]H6V!+#sE0Q
_+=`K$5TI|4I0-=Cp%pt~L#QYydO'iBXR~\tT?uftep9n9AF`@SzTwsw6uqJ}pL,h(cZi}T#PB"#!k
p^e=Z.K~fuw$l?]lUV)?R]U}l;f*~Ol)#fpKR)Yt}XOr6BI\_Jjr0!@GMnpCTnTym4f;c{;Ms=0{`D
Lq9MO6{wj%s-*N"G,g
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Stephan Szabo <sszabo@megazone23.bigpanda.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: [GENERAL] child table doesn't inherit PRIMARY KEY?
In-reply-to: Message from Bruce Momjian <pgman@candle.pha.pa.us>
of Wed, 24 Jan 2001 14:31:29 EST. <200101241931.OAA26463@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 24 Jan 2001 21:41:39 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>
Status: OR
Bruce Momjian wrote:
>> On Wed, 24 Jan 2001, Bruce Momjian wrote:
>I smell TODO item. In fact, I now see a TODO item:
>
>* Unique index on base column not honored on inserts from inherited table
> INSERT INTO inherit_table (unique_index_col) VALUES (dup) should fail
> [inherit]
>
>So it seems the fact the UNIQUE doesn't apply to the new table is just a
>manifestion of the fact that people expect UNIQUE to span the entire
>inheritance tree. I will add the emails to [inherit] and mark it as
>resolved.
Bruce, could you add this text to TODO.detail on the subject of
inherited constraints. I first sent it on Christmas Eve, and I
think most people were too busy holidaying to comment.
=================================================================
Tom Lane wrote:
>Hm. The short-term answer seems to be to modify the queries generated
>by the RI triggers to say "ONLY foo". I am not sure whether we
>understand the semantics involved in allowing a REFERENCES target to be
>taken as an inheritance tree rather than just one table, but certainly
>the current implementation won't handle that correctly.
May I propose these semantics as a basis for future development:
1. An inheritance hierarchy (starting at any point in a tree) should be
equivalent to an updatable view of all the tables at the point of
reference and below. By default, all descendant tables are combined
with the ancestor for all purposes. The keyword ONLY must be used to
alter this behaviour. Only inherited columns of descendant tables are
visible from higher in the tree. Columns may not be dropped in descendants.
If columns are added to ancestors, they must be inserted correctly in
descendants so as to preserve column ordering and inheritance. If
a column is dropped in an ancestor, it is dropped in all descendants.
2. Insertion into a hierarchy means insertion into the table named in
the INSERT statement; updating or deletion affects whichever table(s)
the affected rows are found in. Updating cannot move a row from one
table to another.
3. Inheritance of a table implies inheriting all its constraints unless
ONLY is used or the constraints are subsequently dropped; again, dropping
operates through all descendant tables. A primary key, foreign key or
unique constraint cannot be dropped or modified for a descendant. A
unique index on a column is shared by all tables below the table for
which it is declared. It cannot be dropped for any descendant.
In other words, only NOT NULL and CHECK constraints can be dropped in
descendants.
In multiple inheritance, a column may inherit multiple unique indices
from its several ancestors. All inherited constraints must be satisfied
together (though check constraints may be dropped).
4. RI to a table implies the inclusion of all its descendants in the
check. Since a referenced column may be uniquely indexed further up
the hierarchy than in the table named, the check must ensure that
the referenced value occurs in the right segment of the hierarchy. RI
to one particular level of the hierarchy, excluding descendants, requires
the use of ONLY in the constraint.
5. Dropping a table implies dropping all its descendants.
6. Changes of permissions on a table propagate to all its descendants.
Permissions on descendants may be looser than those on ancestors; they
may not be more restrictive.
This scheme is a lot more restrictive than C++'s or Eiffel's definition
of inheritance, but it seems to me to make the concept truly useful,
without introducing excessive complexity.
============================================================
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"If anyone has material possessions and sees his
brother in need but has no pity on him, how can the
love of God be in him?"
I John 3:17