From 3341052ef337eeccc8c6987e739048df94a5fda1 Mon Sep 17 00:00:00 2001
From: Bruce Momjian <bruce@momjian.us>
Date: Tue, 9 Nov 2004 03:01:48 +0000
Subject: [PATCH] Remove inheritance, already in TODO.
---
doc/TODO.detail/inheritance | 1111 -----------------------------------
1 file changed, 1111 deletions(-)
delete mode 100644 doc/TODO.detail/inheritance
diff --git a/doc/TODO.detail/inheritance b/doc/TODO.detail/inheritance
deleted file mode 100644
index b3112d60779..00000000000
--- a/doc/TODO.detail/inheritance
+++ /dev/null
@@ -1,1111 +0,0 @@
-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)
-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)
-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.
-
-
-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)
-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)
-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
-
-
-
-
-
-
-
-
-
-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
-
-
-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
-
-************
-
-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äg 10:115
-peter_e@gmx.net 75262 Uppsala
-http://yi.org/peter-e/ Sweden
-
-
-
-************
-
-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)
-Received: from news.tht.net (news.hub.org [216.126.91.242]) by renoir.op.net (o1/$Revision: 1.2 $) with ESMTP id WAA20977 for <pgman@candle.pha.pa.us>; Sat, 3 Jun 2000 22:05:07 -0400 (EDT)
-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ä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.
-
-
-
-
-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
-
-
-
-From pgsql-hackers-owner+M9621@postgresql.org Mon Jun 4 21:53:36 2001
-Return-path: <pgsql-hackers-owner+M9621@postgresql.org>
-Received: from postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f551rac27536
- for <pgman@candle.pha.pa.us>; Mon, 4 Jun 2001 21:53:36 -0400 (EDT)
-Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28])
- by postgresql.org (8.11.3/8.11.1) with SMTP id f551prE11747;
- Mon, 4 Jun 2001 21:51:53 -0400 (EDT)
- (envelope-from pgsql-hackers-owner+M9621@postgresql.org)
-Received: from mail-smtp01.one.net.au (mail-smtp01.one.net.au [61.12.0.171])
- by postgresql.org (8.11.3/8.11.1) with SMTP id f551h5E09330
- for <pgsql-hackers@postgresql.org>; Mon, 4 Jun 2001 21:43:05 -0400 (EDT)
- (envelope-from chriskl@familyhealth.com.au)
-Received: (qmail 20200 invoked from network); 5 Jun 2001 01:43:02 -0000
-Received: from unknown (HELO houston.familyhealth.com.au) (203.101.44.22)
- by mail-smtp01.one.net.au with SMTP; 5 Jun 2001 01:43:02 -0000
-Received: from mariner (MARINER.internal [192.168.0.101])
- by houston.familyhealth.com.au (8.11.2/8.11.2) with SMTP id f551cke95391
- for <pgsql-hackers@postgresql.org>; Tue, 5 Jun 2001 09:38:47 +0800 (WST)
- (envelope-from chriskl@familyhealth.com.au)
-From: "Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
-To: "Hackers" <pgsql-hackers@postgresql.org>
-Subject: [HACKERS] Question about inheritance
-Date: Tue, 5 Jun 2001 09:42:38 +0800
-Message-ID: <ECEHIKNFIMMECLEBJFIGEENPCAAA.chriskl@familyhealth.com.au>
-MIME-Version: 1.0
-Content-Type: text/plain;
- charset="iso-8859-1"
-Content-Transfer-Encoding: 7bit
-X-Priority: 3 (Normal)
-X-MSMail-Priority: Normal
-X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
-X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
-Importance: Normal
-Precedence: bulk
-Sender: pgsql-hackers-owner@postgresql.org
-Status: OR
-
-Hi guys,
-
-It's relatively straightforward to allow check constraints to be inherited -
-but is it really possible to ever do the same with primary, unique or even
-foreign constraints?
-
-ie. Say a table has a primary key and I inherit from this table. Since the
-primary key is an index on the parent table, I could just create another
-index on the child table, on the same column.
-
-However - because we are dealing with two separate indices, it should still
-be possible to insert duplicate values into the parent table and the child
-table shouldn't it? This means that when a query is run over the parent
-table that includes results from the child table then you will get duplicate
-results in a supposedly primary index.
-
-Similar arguments seem to apply to unique and foreign constraints. If you
-could use aggregate functions in check constraints - you'd have another
-problem. And if asserts were ever implemented - same thing...
-
-Am I misunderstanding how the mechanism works, or is this a big, not easily
-solved, problem?
-
-Chris
-
-
----------------------------(end of broadcast)---------------------------
-TIP 6: Have you searched our list archives?
-
-http://www.postgresql.org/search.mpl
-
-From pgsql-hackers-owner+M9623@postgresql.org Mon Jun 4 22:17:50 2001
-Return-path: <pgsql-hackers-owner+M9623@postgresql.org>
-Received: from postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f552Hnc29101
- for <pgman@candle.pha.pa.us>; Mon, 4 Jun 2001 22:17:49 -0400 (EDT)
-Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28])
- by postgresql.org (8.11.3/8.11.1) with SMTP id f552GUE19667;
- Mon, 4 Jun 2001 22:16:30 -0400 (EDT)
- (envelope-from pgsql-hackers-owner+M9623@postgresql.org)
-Received: from sss.pgh.pa.us ([192.204.191.242])
- by postgresql.org (8.11.3/8.11.1) with ESMTP id f55281E16781
- for <pgsql-hackers@postgresql.org>; Mon, 4 Jun 2001 22:08:01 -0400 (EDT)
- (envelope-from tgl@sss.pgh.pa.us)
-Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
- by sss.pgh.pa.us (8.11.3/8.11.3) with ESMTP id f5527gR11252;
- Mon, 4 Jun 2001 22:07:42 -0400 (EDT)
-To: "Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
-cc: "Hackers" <pgsql-hackers@postgresql.org>
-Subject: Re: [HACKERS] Question about inheritance
-In-Reply-To: <ECEHIKNFIMMECLEBJFIGEENPCAAA.chriskl@familyhealth.com.au>
-References: <ECEHIKNFIMMECLEBJFIGEENPCAAA.chriskl@familyhealth.com.au>
-Comments: In-reply-to "Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
- message dated "Tue, 05 Jun 2001 09:42:38 +0800"
-Date: Mon, 04 Jun 2001 22:07:42 -0400
-Message-ID: <11249.991706862@sss.pgh.pa.us>
-From: Tom Lane <tgl@sss.pgh.pa.us>
-Precedence: bulk
-Sender: pgsql-hackers-owner@postgresql.org
-Status: OR
-
-"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
-> Am I misunderstanding how the mechanism works, or is this a big, not easily
-> solved, problem?
-
-The latter. Check the list archives for previous debates about this.
-It's not real clear whether an inherited primary key should be expected
-to be unique across the whole inheritance tree, or only unique per-table
-(IIRC, plausible examples have been advanced for each case). If we want
-uniqueness across multiple tables, it'll take considerable work to
-create an index mechanism that'd enforce it.
-
- regards, tom lane
-
----------------------------(end of broadcast)---------------------------
-TIP 5: Have you checked our extensive FAQ?
-
-http://www.postgresql.org/users-lounge/docs/faq.html
-
-From pgsql-hackers-owner+M9664@postgresql.org Tue Jun 5 17:56:17 2001
-Return-path: <pgsql-hackers-owner+M9664@postgresql.org>
-Received: from postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f55LuHc05888
- for <pgman@candle.pha.pa.us>; Tue, 5 Jun 2001 17:56:17 -0400 (EDT)
-Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28])
- by postgresql.org (8.11.3/8.11.1) with SMTP id f55LsqE25492;
- Tue, 5 Jun 2001 17:54:52 -0400 (EDT)
- (envelope-from pgsql-hackers-owner+M9664@postgresql.org)
-Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28])
- by postgresql.org (8.11.3/8.11.1) with SMTP id f55JA9E52724
- for <pgsql-hackers@postgresql.org>; Tue, 5 Jun 2001 15:10:09 -0400 (EDT)
- (envelope-from pgsql-hackers-owner@postgresql.org)
-Received: from iolite.sge.net (iolite.sge.net [152.91.14.26])
- by postgresql.org (8.11.3/8.11.1) with ESMTP id f5539fE34561
- for <pgsql-hackers@postgresql.org>; Mon, 4 Jun 2001 23:09:41 -0400 (EDT)
- (envelope-from chris.bitmead@health.gov.au)
-Received: from cadmium.sge.net (cadmium.sge.net [152.91.9.5])
- by iolite.sge.net (Postfix) with ESMTP id D8401BF05
- for <pgsql-hackers@postgresql.org>; Tue, 5 Jun 2001 13:08:58 +1000 (EST)
-Received: from kryptonite2.sge.net (kryptonite2.sge.net [10.1.2.20])
- by cadmium.sge.net (Postfix) with ESMTP id B0AD3C7902
- for <pgsql-hackers@postgresql.org>; Tue, 5 Jun 2001 13:08:58 +1000 (EST)
-Received: from thorium2.sge.net (thorium2.sge.net [10.1.2.36])
- by kryptonite2.sge.net (Postfix) with SMTP id 4945E3CF05
- for <pgsql-hackers@postgresql.org>; Tue, 5 Jun 2001 13:08:58 +1000 (EST)
-Received: FROM emerald.sge.net BY thorium2.sge.net ; Tue Jun 05 13:00:12 2001 +1000
-Received: from voggite.sge.net (voggite [163.127.224.126])
- by emerald.sge.net (Postfix) with ESMTP id 66A9AE3818
- for <pgsql-hackers@postgresql.org>; Tue, 5 Jun 2001 13:09:52 +1000 (EST)
-Received: from mswcbr02.act.health.gov.au (mswcbr02.act.health.gov.au [163.127.224.137])
- by voggite.sge.net (Postfix) with ESMTP id E863AD0484
- for <pgsql-hackers@postgresql.org>; Tue, 5 Jun 2001 13:09:52 +1000 (EST)
-Received: from mtascbr01.notes.health.gov.au (unverified) by mswcbr02.act.health.gov.au
- (Content Technologies SMTPRS 2.0.15) with SMTP id <B0010037764@mswcbr02.act.health.gov.au> for <pgsql-hackers@postgresql.org>;
- Tue, 05 Jun 2001 13:18:48 +1000
-Received: by mtascbr01.notes.health.gov.au(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id CA256A62.0011CDDB ; Tue, 5 Jun 2001 13:14:28 +1000
-X-Lotus-FromDomain: HEALTH_GOV_AU
-From: chris.bitmead@health.gov.au
-Reply-To: chris.bitmead@health.gov.au
-To: pgsql-hackers@postgresql.org
-Message-ID: <CA256A62.0011CAAF.00@mtascbr01.notes.health.gov.au>
-Date: Tue, 5 Jun 2001 13:08:58 +1000
-Subject: Re: [HACKERS] Question about inheritance
-MIME-Version: 1.0
-Content-Type: text/plain; charset=us-ascii
-Content-Disposition: inline
-Precedence: bulk
-Sender: pgsql-hackers-owner@postgresql.org
-Status: OR
-
-
-
-
->It's relatively straightforward to allow check constraints to be inherited -
->but is it really possible to ever do the same with primary, unique or even
->foreign constraints?
-
-You would either have to check each index in the hierarchy or else have
-a single index across the whole hierarchy and check that. Obviously the
-latter would be generally more useful.
-
-As with all things inheritance, it is usually the right thing, and a good
-default that things be inherited. So ideally, indexes should work across
-whole hierarchies as well as primary, unique and foreign constraints.
-It could be argued that not inheriting is of very limited usefulness.
-
-
-
-
----------------------------(end of broadcast)---------------------------
-TIP 4: Don't 'kill -9' the postmaster
-
-From pgsql-hackers-owner+M9627@postgresql.org Mon Jun 4 23:58:36 2001
-Return-path: <pgsql-hackers-owner+M9627@postgresql.org>
-Received: from postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f553wac02588
- for <pgman@candle.pha.pa.us>; Mon, 4 Jun 2001 23:58:36 -0400 (EDT)
-Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28])
- by postgresql.org (8.11.3/8.11.1) with SMTP id f553vAE48166;
- Mon, 4 Jun 2001 23:57:10 -0400 (EDT)
- (envelope-from pgsql-hackers-owner+M9627@postgresql.org)
-Received: from megazone23.bigpanda.com ([216.136.151.41])
- by postgresql.org (8.11.3/8.11.1) with ESMTP id f553ksE45147
- for <pgsql-hackers@postgresql.org>; Mon, 4 Jun 2001 23:46:54 -0400 (EDT)
- (envelope-from sszabo@megazone23.bigpanda.com)
-Received: from localhost (sszabo@localhost)
- by megazone23.bigpanda.com (8.11.2/8.11.2) with ESMTP id f553kYc07461;
- Mon, 4 Jun 2001 20:46:38 -0700 (PDT)
-Date: Mon, 4 Jun 2001 20:46:34 -0700 (PDT)
-From: Stephan Szabo <sszabo@megazone23.bigpanda.com>
-To: Christopher Kings-Lynne <chriskl@familyhealth.com.au>
-cc: Hackers <pgsql-hackers@postgresql.org>
-Subject: Re: [HACKERS] Question about inheritance
-In-Reply-To: <ECEHIKNFIMMECLEBJFIGEENPCAAA.chriskl@familyhealth.com.au>
-Message-ID: <Pine.BSF.4.21.0106042039040.7433-100000@megazone23.bigpanda.com>
-MIME-Version: 1.0
-Content-Type: TEXT/PLAIN; charset=US-ASCII
-Precedence: bulk
-Sender: pgsql-hackers-owner@postgresql.org
-Status: OR
-
-On Tue, 5 Jun 2001, Christopher Kings-Lynne wrote:
-
-> Hi guys,
->
-> It's relatively straightforward to allow check constraints to be inherited -
-> but is it really possible to ever do the same with primary, unique or even
-> foreign constraints?
->
-> ie. Say a table has a primary key and I inherit from this table. Since the
-> primary key is an index on the parent table, I could just create another
-> index on the child table, on the same column.
->
-> However - because we are dealing with two separate indices, it should still
-> be possible to insert duplicate values into the parent table and the child
-> table shouldn't it? This means that when a query is run over the parent
-> table that includes results from the child table then you will get duplicate
-> results in a supposedly primary index.
->
-> Similar arguments seem to apply to unique and foreign constraints. If you
-> could use aggregate functions in check constraints - you'd have another
-> problem. And if asserts were ever implemented - same thing...
->
-> Am I misunderstanding how the mechanism works, or is this a big, not easily
-> solved, problem?
-
-It's a big deal. Actually check constraints have a similar problem if you
-allow inherited constraints to be dropped. "Why does 'select * from
-base;' give me rows where value<10 since there's a check value>=10
-on the table?"
-
-As Tom said, the unique constraint thing is still questionable which is
-the more meaningful semantics. If we ever want to allow foreign key
-constraints to inheritance trees, we need *some* way to guarantees
-uniqueness across the tree even if that isn't through the unique
-constraint.
-
-
----------------------------(end of broadcast)---------------------------
-TIP 6: Have you searched our list archives?
-
-http://www.postgresql.org/search.mpl
-
-From pgsql-hackers-owner+M9638@postgresql.org Tue Jun 5 06:30:37 2001
-Return-path: <pgsql-hackers-owner+M9638@postgresql.org>
-Received: from postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f55AUac21070
- for <pgman@candle.pha.pa.us>; Tue, 5 Jun 2001 06:30:36 -0400 (EDT)
-Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28])
- by postgresql.org (8.11.3/8.11.1) with SMTP id f55AT9E31492;
- Tue, 5 Jun 2001 06:29:09 -0400 (EDT)
- (envelope-from pgsql-hackers-owner+M9638@postgresql.org)
-Received: from ajax2.sovam.com (ajax2.sovam.com [194.67.1.173])
- by postgresql.org (8.11.3/8.11.1) with ESMTP id f55AJXE27449
- for <pgsql-hackers@postgresql.org>; Tue, 5 Jun 2001 06:19:33 -0400 (EDT)
- (envelope-from dmitry@taurussoft.org)
-Received: from pm14-a43.dial.sovam.com ([195.218.132.43]:1047 "HELO
- taurussoft.org" ident: "TIMEDOUT2" whoson: "tttt@online.ru" smtp-auth:
- <none> TLS-CIPHER: <none> TLS-PEER: <none>) by ajax2.sovam.com
- with SMTP id <S400880AbRFEKTP>; Tue, 5 Jun 2001 14:19:15 +0400
-Received: (qmail 610 invoked from network); 5 Jun 2001 10:16:54 -0000
-Received: from flame-in-night.taurussoft.org (HELO flameinnight) (192.168.107.1)
- by kitezh.taurussoft.org with SMTP; 5 Jun 2001 10:16:54 -0000
-Message-ID: <008901c0eda8$bc6fb520$016ba8c0@taurussoft.org>
-From: "Dmitry G. Mastrukov" <dmitry@taurussoft.org>
-To: <pgsql-hackers@postgresql.org>
-Subject: Re: [HACKERS] Question about inheritance
-Date: Tue, 5 Jun 2001 14:17:33 +0400
-MIME-Version: 1.0
-Content-Type: text/plain;
- charset="koi8-r"
-Content-Transfer-Encoding: 7bit
-X-Priority: 3
-X-MSMail-Priority: Normal
-X-Mailer: Microsoft Outlook Express 5.00.2615.200
-X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
-Precedence: bulk
-Sender: pgsql-hackers-owner@postgresql.org
-Status: OR
-
- > "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
- > > Am I misunderstanding how the mechanism works, or is this a big, not
- easily
- > > solved, problem?
- >
- > The latter. Check the list archives for previous debates about this.
- > It's not real clear whether an inherited primary key should be expected
- > to be unique across the whole inheritance tree, or only unique per-table
- > (IIRC, plausible examples have been advanced for each case). If we want
- > uniqueness across multiple tables, it'll take considerable work to
- > create an index mechanism that'd enforce it.
- >
- IMHO current behaviour of PostgreSQL with inherited PK, FK, UNIQUE is
-simply
- bug not only from object-oriented but even object-related point of view.
-Now
- I can violate parent PK by inserting duplicate key in child!
-
- Inherited tables should honours all constraints from parent. If I change
- some constraint (seems only FK, but not PK or UNIQUE) I should be able to
-do
- it in more restrictive manner. For example, two base table is connected via
- FK. I can change such FK in childs from base1->base2 to child1->child2 (or
- child3) but not to child1->not_inherited_from_base2. CHECK, DEFAULT, NOT
- NULL are more free to changes, isn't it?
-
- IMHO last message in doc/TODO.details/inheritance from Oliver Elphick is a
- good direction for implementing with exception on more rectrictive child FK
- constraint (p.3 of message).
-
- As for me, I was pushed to rollback to scheme with no inheritance at all in
- my project for now. So I'm very interesting in implementing of right
- inheritance and I wanted to ask similar question in one of the lists in
-near
- future.
-
- Regards,
- Dmitry
-
-
-
-
----------------------------(end of broadcast)---------------------------
-TIP 6: Have you searched our list archives?
-
-http://www.postgresql.org/search.mpl
-
--
GitLab