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.1 $) 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 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)
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.14 $) 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.
+
+
+
+
OSDN Git Service
