Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 5021fcb

Browse files
bmomjianbmomjian
committed
Add inheritance.
1 parent 23c25ab commit 5021fcb

File tree

1 file changed

+346
-1
lines changed

1 file changed

+346
-1
lines changed

‎doc/TODO.detail/inheritance

Lines changed: 346 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -520,7 +520,7 @@ From pgsql-general-owner+M2136@hub.org Sat Jun 3 23:31:02 2000
520520
Received: from renoir.op.net (root@renoir.op.net [207.29.195.4])
521521
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id WAA28683
522522
for <pgman@candle.pha.pa.us>; Sat, 3 Jun 2000 22:31:01 -0400 (EDT)
523-
Received: from news.tht.net (news.hub.org [216.126.91.242]) by renoir.op.net (o1/$Revision: 1.1 $) with ESMTP id WAA20977 for <pgman@candle.pha.pa.us>; Sat, 3 Jun 2000 22:05:07 -0400 (EDT)
523+
Received: from news.tht.net (news.hub.org [216.126.91.242]) by renoir.op.net (o1/$Revision: 1.2 $) with ESMTP id WAA20977 for <pgman@candle.pha.pa.us>; Sat, 3 Jun 2000 22:05:07 -0400 (EDT)
524524
Received: from hub.org (majordom@hub.org [216.126.84.1])
525525
by news.tht.net (8.9.3/8.9.3) with ESMTP id VAD35811;
526526
Sat, 3 Jun 2000 21:54:36 -0400 (EDT)
@@ -764,3 +764,348 @@ GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
764764

765765

766766

767+
From pgsql-hackers-owner+M9621@postgresql.org Mon Jun 4 21:53:36 2001
768+
Return-path: <pgsql-hackers-owner+M9621@postgresql.org>
769+
Received: from postgresql.org (webmail.postgresql.org [216.126.85.28])
770+
by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f551rac27536
771+
for <pgman@candle.pha.pa.us>; Mon, 4 Jun 2001 21:53:36 -0400 (EDT)
772+
Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28])
773+
by postgresql.org (8.11.3/8.11.1) with SMTP id f551prE11747;
774+
Mon, 4 Jun 2001 21:51:53 -0400 (EDT)
775+
(envelope-from pgsql-hackers-owner+M9621@postgresql.org)
776+
Received: from mail-smtp01.one.net.au (mail-smtp01.one.net.au [61.12.0.171])
777+
by postgresql.org (8.11.3/8.11.1) with SMTP id f551h5E09330
778+
for <pgsql-hackers@postgresql.org>; Mon, 4 Jun 2001 21:43:05 -0400 (EDT)
779+
(envelope-from chriskl@familyhealth.com.au)
780+
Received: (qmail 20200 invoked from network); 5 Jun 2001 01:43:02 -0000
781+
Received: from unknown (HELO houston.familyhealth.com.au) (203.101.44.22)
782+
by mail-smtp01.one.net.au with SMTP; 5 Jun 2001 01:43:02 -0000
783+
Received: from mariner (MARINER.internal [192.168.0.101])
784+
by houston.familyhealth.com.au (8.11.2/8.11.2) with SMTP id f551cke95391
785+
for <pgsql-hackers@postgresql.org>; Tue, 5 Jun 2001 09:38:47 +0800 (WST)
786+
(envelope-from chriskl@familyhealth.com.au)
787+
From: "Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
788+
To: "Hackers" <pgsql-hackers@postgresql.org>
789+
Subject: [HACKERS] Question about inheritance
790+
Date: Tue, 5 Jun 2001 09:42:38 +0800
791+
Message-ID: <ECEHIKNFIMMECLEBJFIGEENPCAAA.chriskl@familyhealth.com.au>
792+
MIME-Version: 1.0
793+
Content-Type: text/plain;
794+
charset="iso-8859-1"
795+
Content-Transfer-Encoding: 7bit
796+
X-Priority: 3 (Normal)
797+
X-MSMail-Priority: Normal
798+
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
799+
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
800+
Importance: Normal
801+
Precedence: bulk
802+
Sender: pgsql-hackers-owner@postgresql.org
803+
Status: OR
804+
805+
Hi guys,
806+
807+
It's relatively straightforward to allow check constraints to be inherited -
808+
but is it really possible to ever do the same with primary, unique or even
809+
foreign constraints?
810+
811+
ie. Say a table has a primary key and I inherit from this table. Since the
812+
primary key is an index on the parent table, I could just create another
813+
index on the child table, on the same column.
814+
815+
However - because we are dealing with two separate indices, it should still
816+
be possible to insert duplicate values into the parent table and the child
817+
table shouldn't it? This means that when a query is run over the parent
818+
table that includes results from the child table then you will get duplicate
819+
results in a supposedly primary index.
820+
821+
Similar arguments seem to apply to unique and foreign constraints. If you
822+
could use aggregate functions in check constraints - you'd have another
823+
problem. And if asserts were ever implemented - same thing...
824+
825+
Am I misunderstanding how the mechanism works, or is this a big, not easily
826+
solved, problem?
827+
828+
Chris
829+
830+
831+
---------------------------(end of broadcast)---------------------------
832+
TIP 6: Have you searched our list archives?
833+
834+
http://www.postgresql.org/search.mpl
835+
836+
From pgsql-hackers-owner+M9623@postgresql.org Mon Jun 4 22:17:50 2001
837+
Return-path: <pgsql-hackers-owner+M9623@postgresql.org>
838+
Received: from postgresql.org (webmail.postgresql.org [216.126.85.28])
839+
by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f552Hnc29101
840+
for <pgman@candle.pha.pa.us>; Mon, 4 Jun 2001 22:17:49 -0400 (EDT)
841+
Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28])
842+
by postgresql.org (8.11.3/8.11.1) with SMTP id f552GUE19667;
843+
Mon, 4 Jun 2001 22:16:30 -0400 (EDT)
844+
(envelope-from pgsql-hackers-owner+M9623@postgresql.org)
845+
Received: from sss.pgh.pa.us ([192.204.191.242])
846+
by postgresql.org (8.11.3/8.11.1) with ESMTP id f55281E16781
847+
for <pgsql-hackers@postgresql.org>; Mon, 4 Jun 2001 22:08:01 -0400 (EDT)
848+
(envelope-from tgl@sss.pgh.pa.us)
849+
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
850+
by sss.pgh.pa.us (8.11.3/8.11.3) with ESMTP id f5527gR11252;
851+
Mon, 4 Jun 2001 22:07:42 -0400 (EDT)
852+
To: "Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
853+
cc: "Hackers" <pgsql-hackers@postgresql.org>
854+
Subject: Re: [HACKERS] Question about inheritance
855+
In-Reply-To: <ECEHIKNFIMMECLEBJFIGEENPCAAA.chriskl@familyhealth.com.au>
856+
References: <ECEHIKNFIMMECLEBJFIGEENPCAAA.chriskl@familyhealth.com.au>
857+
Comments: In-reply-to "Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
858+
message dated "Tue, 05 Jun 2001 09:42:38 +0800"
859+
Date: Mon, 04 Jun 2001 22:07:42 -0400
860+
Message-ID: <11249.991706862@sss.pgh.pa.us>
861+
From: Tom Lane <tgl@sss.pgh.pa.us>
862+
Precedence: bulk
863+
Sender: pgsql-hackers-owner@postgresql.org
864+
Status: OR
865+
866+
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
867+
> Am I misunderstanding how the mechanism works, or is this a big, not easily
868+
> solved, problem?
869+
870+
The latter. Check the list archives for previous debates about this.
871+
It's not real clear whether an inherited primary key should be expected
872+
to be unique across the whole inheritance tree, or only unique per-table
873+
(IIRC, plausible examples have been advanced for each case). If we want
874+
uniqueness across multiple tables, it'll take considerable work to
875+
create an index mechanism that'd enforce it.
876+
877+
regards, tom lane
878+
879+
---------------------------(end of broadcast)---------------------------
880+
TIP 5: Have you checked our extensive FAQ?
881+
882+
http://www.postgresql.org/users-lounge/docs/faq.html
883+
884+
From pgsql-hackers-owner+M9664@postgresql.org Tue Jun 5 17:56:17 2001
885+
Return-path: <pgsql-hackers-owner+M9664@postgresql.org>
886+
Received: from postgresql.org (webmail.postgresql.org [216.126.85.28])
887+
by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f55LuHc05888
888+
for <pgman@candle.pha.pa.us>; Tue, 5 Jun 2001 17:56:17 -0400 (EDT)
889+
Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28])
890+
by postgresql.org (8.11.3/8.11.1) with SMTP id f55LsqE25492;
891+
Tue, 5 Jun 2001 17:54:52 -0400 (EDT)
892+
(envelope-from pgsql-hackers-owner+M9664@postgresql.org)
893+
Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28])
894+
by postgresql.org (8.11.3/8.11.1) with SMTP id f55JA9E52724
895+
for <pgsql-hackers@postgresql.org>; Tue, 5 Jun 2001 15:10:09 -0400 (EDT)
896+
(envelope-from pgsql-hackers-owner@postgresql.org)
897+
Received: from iolite.sge.net (iolite.sge.net [152.91.14.26])
898+
by postgresql.org (8.11.3/8.11.1) with ESMTP id f5539fE34561
899+
for <pgsql-hackers@postgresql.org>; Mon, 4 Jun 2001 23:09:41 -0400 (EDT)
900+
(envelope-from chris.bitmead@health.gov.au)
901+
Received: from cadmium.sge.net (cadmium.sge.net [152.91.9.5])
902+
by iolite.sge.net (Postfix) with ESMTP id D8401BF05
903+
for <pgsql-hackers@postgresql.org>; Tue, 5 Jun 2001 13:08:58 +1000 (EST)
904+
Received: from kryptonite2.sge.net (kryptonite2.sge.net [10.1.2.20])
905+
by cadmium.sge.net (Postfix) with ESMTP id B0AD3C7902
906+
for <pgsql-hackers@postgresql.org>; Tue, 5 Jun 2001 13:08:58 +1000 (EST)
907+
Received: from thorium2.sge.net (thorium2.sge.net [10.1.2.36])
908+
by kryptonite2.sge.net (Postfix) with SMTP id 4945E3CF05
909+
for <pgsql-hackers@postgresql.org>; Tue, 5 Jun 2001 13:08:58 +1000 (EST)
910+
Received: FROM emerald.sge.net BY thorium2.sge.net ; Tue Jun 05 13:00:12 2001 +1000
911+
Received: from voggite.sge.net (voggite [163.127.224.126])
912+
by emerald.sge.net (Postfix) with ESMTP id 66A9AE3818
913+
for <pgsql-hackers@postgresql.org>; Tue, 5 Jun 2001 13:09:52 +1000 (EST)
914+
Received: from mswcbr02.act.health.gov.au (mswcbr02.act.health.gov.au [163.127.224.137])
915+
by voggite.sge.net (Postfix) with ESMTP id E863AD0484
916+
for <pgsql-hackers@postgresql.org>; Tue, 5 Jun 2001 13:09:52 +1000 (EST)
917+
Received: from mtascbr01.notes.health.gov.au (unverified) by mswcbr02.act.health.gov.au
918+
(Content Technologies SMTPRS 2.0.15) with SMTP id <B0010037764@mswcbr02.act.health.gov.au> for <pgsql-hackers@postgresql.org>;
919+
Tue, 05 Jun 2001 13:18:48 +1000
920+
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
921+
X-Lotus-FromDomain: HEALTH_GOV_AU
922+
From: chris.bitmead@health.gov.au
923+
Reply-To: chris.bitmead@health.gov.au
924+
To: pgsql-hackers@postgresql.org
925+
Message-ID: <CA256A62.0011CAAF.00@mtascbr01.notes.health.gov.au>
926+
Date: Tue, 5 Jun 2001 13:08:58 +1000
927+
Subject: Re: [HACKERS] Question about inheritance
928+
MIME-Version: 1.0
929+
Content-Type: text/plain; charset=us-ascii
930+
Content-Disposition: inline
931+
Precedence: bulk
932+
Sender: pgsql-hackers-owner@postgresql.org
933+
Status: OR
934+
935+
936+
937+
938+
>It's relatively straightforward to allow check constraints to be inherited -
939+
>but is it really possible to ever do the same with primary, unique or even
940+
>foreign constraints?
941+
942+
You would either have to check each index in the hierarchy or else have
943+
a single index across the whole hierarchy and check that. Obviously the
944+
latter would be generally more useful.
945+
946+
As with all things inheritance, it is usually the right thing, and a good
947+
default that things be inherited. So ideally, indexes should work across
948+
whole hierarchies as well as primary, unique and foreign constraints.
949+
It could be argued that not inheriting is of very limited usefulness.
950+
951+
952+
953+
954+
---------------------------(end of broadcast)---------------------------
955+
TIP 4: Don't 'kill -9' the postmaster
956+
957+
From pgsql-hackers-owner+M9627@postgresql.org Mon Jun 4 23:58:36 2001
958+
Return-path: <pgsql-hackers-owner+M9627@postgresql.org>
959+
Received: from postgresql.org (webmail.postgresql.org [216.126.85.28])
960+
by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f553wac02588
961+
for <pgman@candle.pha.pa.us>; Mon, 4 Jun 2001 23:58:36 -0400 (EDT)
962+
Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28])
963+
by postgresql.org (8.11.3/8.11.1) with SMTP id f553vAE48166;
964+
Mon, 4 Jun 2001 23:57:10 -0400 (EDT)
965+
(envelope-from pgsql-hackers-owner+M9627@postgresql.org)
966+
Received: from megazone23.bigpanda.com ([216.136.151.41])
967+
by postgresql.org (8.11.3/8.11.1) with ESMTP id f553ksE45147
968+
for <pgsql-hackers@postgresql.org>; Mon, 4 Jun 2001 23:46:54 -0400 (EDT)
969+
(envelope-from sszabo@megazone23.bigpanda.com)
970+
Received: from localhost (sszabo@localhost)
971+
by megazone23.bigpanda.com (8.11.2/8.11.2) with ESMTP id f553kYc07461;
972+
Mon, 4 Jun 2001 20:46:38 -0700 (PDT)
973+
Date: Mon, 4 Jun 2001 20:46:34 -0700 (PDT)
974+
From: Stephan Szabo <sszabo@megazone23.bigpanda.com>
975+
To: Christopher Kings-Lynne <chriskl@familyhealth.com.au>
976+
cc: Hackers <pgsql-hackers@postgresql.org>
977+
Subject: Re: [HACKERS] Question about inheritance
978+
In-Reply-To: <ECEHIKNFIMMECLEBJFIGEENPCAAA.chriskl@familyhealth.com.au>
979+
Message-ID: <Pine.BSF.4.21.0106042039040.7433-100000@megazone23.bigpanda.com>
980+
MIME-Version: 1.0
981+
Content-Type: TEXT/PLAIN; charset=US-ASCII
982+
Precedence: bulk
983+
Sender: pgsql-hackers-owner@postgresql.org
984+
Status: OR
985+
986+
On Tue, 5 Jun 2001, Christopher Kings-Lynne wrote:
987+
988+
> Hi guys,
989+
>
990+
> It's relatively straightforward to allow check constraints to be inherited -
991+
> but is it really possible to ever do the same with primary, unique or even
992+
> foreign constraints?
993+
>
994+
> ie. Say a table has a primary key and I inherit from this table. Since the
995+
> primary key is an index on the parent table, I could just create another
996+
> index on the child table, on the same column.
997+
>
998+
> However - because we are dealing with two separate indices, it should still
999+
> be possible to insert duplicate values into the parent table and the child
1000+
> table shouldn't it? This means that when a query is run over the parent
1001+
> table that includes results from the child table then you will get duplicate
1002+
> results in a supposedly primary index.
1003+
>
1004+
> Similar arguments seem to apply to unique and foreign constraints. If you
1005+
> could use aggregate functions in check constraints - you'd have another
1006+
> problem. And if asserts were ever implemented - same thing...
1007+
>
1008+
> Am I misunderstanding how the mechanism works, or is this a big, not easily
1009+
> solved, problem?
1010+
1011+
It's a big deal. Actually check constraints have a similar problem if you
1012+
allow inherited constraints to be dropped. "Why does 'select * from
1013+
base;' give me rows where value<10 since there's a check value>=10
1014+
on the table?"
1015+
1016+
As Tom said, the unique constraint thing is still questionable which is
1017+
the more meaningful semantics. If we ever want to allow foreign key
1018+
constraints to inheritance trees, we need *some* way to guarantees
1019+
uniqueness across the tree even if that isn't through the unique
1020+
constraint.
1021+
1022+
1023+
---------------------------(end of broadcast)---------------------------
1024+
TIP 6: Have you searched our list archives?
1025+
1026+
http://www.postgresql.org/search.mpl
1027+
1028+
From pgsql-hackers-owner+M9638@postgresql.org Tue Jun 5 06:30:37 2001
1029+
Return-path: <pgsql-hackers-owner+M9638@postgresql.org>
1030+
Received: from postgresql.org (webmail.postgresql.org [216.126.85.28])
1031+
by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f55AUac21070
1032+
for <pgman@candle.pha.pa.us>; Tue, 5 Jun 2001 06:30:36 -0400 (EDT)
1033+
Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28])
1034+
by postgresql.org (8.11.3/8.11.1) with SMTP id f55AT9E31492;
1035+
Tue, 5 Jun 2001 06:29:09 -0400 (EDT)
1036+
(envelope-from pgsql-hackers-owner+M9638@postgresql.org)
1037+
Received: from ajax2.sovam.com (ajax2.sovam.com [194.67.1.173])
1038+
by postgresql.org (8.11.3/8.11.1) with ESMTP id f55AJXE27449
1039+
for <pgsql-hackers@postgresql.org>; Tue, 5 Jun 2001 06:19:33 -0400 (EDT)
1040+
(envelope-from dmitry@taurussoft.org)
1041+
Received: from pm14-a43.dial.sovam.com ([195.218.132.43]:1047 "HELO
1042+
taurussoft.org" ident: "TIMEDOUT2" whoson: "tttt@online.ru" smtp-auth:
1043+
<none> TLS-CIPHER: <none> TLS-PEER: <none>) by ajax2.sovam.com
1044+
with SMTP id <S400880AbRFEKTP>; Tue, 5 Jun 2001 14:19:15 +0400
1045+
Received: (qmail 610 invoked from network); 5 Jun 2001 10:16:54 -0000
1046+
Received: from flame-in-night.taurussoft.org (HELO flameinnight) (192.168.107.1)
1047+
by kitezh.taurussoft.org with SMTP; 5 Jun 2001 10:16:54 -0000
1048+
Message-ID: <008901c0eda8$bc6fb520$016ba8c0@taurussoft.org>
1049+
From: "Dmitry G. Mastrukov" <dmitry@taurussoft.org>
1050+
To: <pgsql-hackers@postgresql.org>
1051+
Subject: Re: [HACKERS] Question about inheritance
1052+
Date: Tue, 5 Jun 2001 14:17:33 +0400
1053+
MIME-Version: 1.0
1054+
Content-Type: text/plain;
1055+
charset="koi8-r"
1056+
Content-Transfer-Encoding: 7bit
1057+
X-Priority: 3
1058+
X-MSMail-Priority: Normal
1059+
X-Mailer: Microsoft Outlook Express 5.00.2615.200
1060+
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
1061+
Precedence: bulk
1062+
Sender: pgsql-hackers-owner@postgresql.org
1063+
Status: OR
1064+
1065+
> "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
1066+
> > Am I misunderstanding how the mechanism works, or is this a big, not
1067+
easily
1068+
> > solved, problem?
1069+
>
1070+
> The latter. Check the list archives for previous debates about this.
1071+
> It's not real clear whether an inherited primary key should be expected
1072+
> to be unique across the whole inheritance tree, or only unique per-table
1073+
> (IIRC, plausible examples have been advanced for each case). If we want
1074+
> uniqueness across multiple tables, it'll take considerable work to
1075+
> create an index mechanism that'd enforce it.
1076+
>
1077+
IMHO current behaviour of PostgreSQL with inherited PK, FK, UNIQUE is
1078+
simply
1079+
bug not only from object-oriented but even object-related point of view.
1080+
Now
1081+
I can violate parent PK by inserting duplicate key in child!
1082+
1083+
Inherited tables should honours all constraints from parent. If I change
1084+
some constraint (seems only FK, but not PK or UNIQUE) I should be able to
1085+
do
1086+
it in more restrictive manner. For example, two base table is connected via
1087+
FK. I can change such FK in childs from base1->base2 to child1->child2 (or
1088+
child3) but not to child1->not_inherited_from_base2. CHECK, DEFAULT, NOT
1089+
NULL are more free to changes, isn't it?
1090+
1091+
IMHO last message in doc/TODO.details/inheritance from Oliver Elphick is a
1092+
good direction for implementing with exception on more rectrictive child FK
1093+
constraint (p.3 of message).
1094+
1095+
As for me, I was pushed to rollback to scheme with no inheritance at all in
1096+
my project for now. So I'm very interesting in implementing of right
1097+
inheritance and I wanted to ask similar question in one of the lists in
1098+
near
1099+
future.
1100+
1101+
Regards,
1102+
Dmitry
1103+
1104+
1105+
1106+
1107+
---------------------------(end of broadcast)---------------------------
1108+
TIP 6: Have you searched our list archives?
1109+
1110+
http://www.postgresql.org/search.mpl
1111+

0 commit comments

Comments
 (0)