From 3341052ef337eeccc8c6987e739048df94a5fda1 Mon Sep 17 00:00:00 2001 From: Bruce Momjian 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 b3112d6077..0000000000 --- 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 ; 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 ; 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 ; 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 ; 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 -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 ; 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 ; 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 ; 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" -From: "Jonathan davis" -To: "Bruce Momjian" -Cc: "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 ; 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 ; 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 ; 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 -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 ; 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 ; 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 ; 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 ; 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 -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 ; Mon, 24 Jan 2000 23:46:24 -0500 (EST) -Received: from localhost (majordom@localhost) - by hub.org (8.9.3/8.9.3) with SMTP id XAA81794; - Mon, 24 Jan 2000 23:01:22 -0500 (EST) - (envelope-from owner-pgsql-hackers) -Received: by hub.org (bulk_mailer v1.5); Mon, 24 Jan 2000 22:59:46 -0500 -Received: (from majordom@localhost) - by hub.org (8.9.3/8.9.3) id WAA80721 - for pgsql-hackers-outgoing; Mon, 24 Jan 2000 22:58:59 -0500 (EST) - (envelope-from owner-pgsql-hackers@postgreSQL.org) -Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) - by hub.org (8.9.3/8.9.3) with ESMTP id WAA80619 - for ; Mon, 24 Jan 2000 22:58:33 -0500 (EST) - (envelope-from tgl@sss.pgh.pa.us) -Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) - by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id WAA11576; - Mon, 24 Jan 2000 22:57:12 -0500 (EST) -To: Don Baccus -cc: "Hiroshi Inoue" , "Peter Eisentraut" , - "PostgreSQL Development" -Subject: Re: [HACKERS] Happy column dropping -In-reply-to: <3.0.1.32.20000124184137.01069490@mail.pacifier.com> -References: <001001bf66d7$b531ba00$2801007e@tpf.co.jp> <001001bf66d7$b531ba00$2801007e@tpf.co.jp> <3.0.1.32.20000124184137.01069490@mail.pacifier.com> -Comments: In-reply-to Don Baccus - message dated "Mon, 24 Jan 2000 18:41:37 -0800" -Date: Mon, 24 Jan 2000 22:57:12 -0500 -Message-ID: <11573.948772632@sss.pgh.pa.us> -From: Tom Lane -Sender: owner-pgsql-hackers@postgreSQL.org -Status: RO - -Don Baccus writes: -> Just a reality check for my learning of the internals. Out of curiousity -> I coincidently have spent the last hour looking to see how add column's -> implemented. It doesn't appear to do anything other than the new attribute -> to the proper system table. heap_getattr() just returns null if you ask -> for an attribute past the end of the tuple. - -> This would appear to be (at least one reason) why you can't add a "not null" -> constraint to a column you're adding to an existing relation, or set the -> new column to some non-null default value. - -> Correct? (again, to see if my eyeballs and brain are working in synch -> tonight) - -Yup, that's about the size of it. ADD COLUMN doesn't actually touch the -table itself, so it can only add a column that's initially all NULLs. -And even this depends on some uncomfortable assumptions about the -robustness of heap_getattr(). I have always wondered whether it works -if you ADD COLUMN a 33'rd column (or anything that is just past the -next padding boundary for the null-values bitmap). - -Another problem with it is seen when you do a recursive ADD COLUMN in -an inheritance tree. The added column has the first free column number -in each table, which generally means that it has different numbers in -the children than in the parent. There are some kluges to make this -sort-of-work for simple cases, but a lot of stuff fails unpleasantly ---- Chris Bitmead can show you some scars from that, IIRC. - -> Does your comment imply that it's planned to change this, i.e. actually -> add the new column to each tuple in the relation rather than use the -> existing, somewhat elegant hack? - -That's what I would like to see: all the children should have the -same column numbers for all columns that they inherit from the parent. - -(Now, this would mean not only physically altering the tuples of -the children, but also renumbering their added columns, which has -implications on stored rules and triggers and so forth. It'd be -painful, no doubt about it. Still, I'd rather pay the price in the -seldom-used ADD COLUMN case than try to deal with out-of-sync column -numbers in many other, more commonly exercised, code paths.) - - regards, tom lane - -************ - -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 ; 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 ; 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 -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 -Cc: Tom Lane , - "Ross J. Reedstrom" , - PostgreSQL Development -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> - - <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 ; 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 ; 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 ; - 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 -To: Tom Lane -cc: PostgreSQL Development -Subject: Re: [HACKERS] Column ADDing issues -In-Reply-To: <15550.948845404@sss.pgh.pa.us> -Message-ID: -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 ; 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 ; 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 ; 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 ; 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 -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: -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 ; 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 -To: Bruce Momjian -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: -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 ; 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 -To: Bruce Momjian -cc: PostgreSQL-development -Subject: Re: [GENERAL] child table doesn't inherit PRIMARY KEY? -In-Reply-To: <200101241344.IAA12094@candle.pha.pa.us> -Message-ID: -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 ; 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 -cc: Stephan Szabo , - PostgreSQL-development -Subject: Re: [HACKERS] Re: [GENERAL] child table doesn't inherit PRIMARY KEY? -In-reply-to: Message from Bruce Momjian - 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" -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: -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 ; 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 ; 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 ; Tue, 5 Jun 2001 09:38:47 +0800 (WST) - (envelope-from chriskl@familyhealth.com.au) -From: "Christopher Kings-Lynne" -To: "Hackers" -Subject: [HACKERS] Question about inheritance -Date: Tue, 5 Jun 2001 09:42:38 +0800 -Message-ID: -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: -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 ; 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 ; 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" -cc: "Hackers" -Subject: Re: [HACKERS] Question about inheritance -In-Reply-To: -References: -Comments: In-reply-to "Christopher Kings-Lynne" - 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 -Precedence: bulk -Sender: pgsql-hackers-owner@postgresql.org -Status: OR - -"Christopher Kings-Lynne" 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: -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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 for ; - 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: -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: -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 ; 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 ; 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 -To: Christopher Kings-Lynne -cc: Hackers -Subject: Re: [HACKERS] Question about inheritance -In-Reply-To: -Message-ID: -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: -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 ; 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 ; 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: - TLS-CIPHER: TLS-PEER: ) by ajax2.sovam.com - with SMTP id ; 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" -To: -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" 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 -