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.1 $) 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