RI problem with inherited table
It no longer seems to be possible to refer to a table, which is an
ancestor of any other, in a referential integrity constraint.
In this example, "person" is the ancestor of several other tables:
bray=# create table junk (id char(10) constraint junk_id_person references
person*(id));
ERROR: parser: parse error at or near "*"
bray=# create table junk (id char(10) constraint junk_id_person references
only person(id));
ERROR: parser: parse error at or near "only"
bray=# create table junk (id char(10) constraint junk_id_person references
person(id));
NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY check(s)
CREATE
bray=# insert into junk values ('aa');
ERROR: SELECT FOR UPDATE is not supported for inherit queries
--
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
========================================
"And there were in the same country shepherds abiding
in the field, keeping watch over their flock by night.
And, lo, the angel of the Lord came upon them, and the
glory of the Lord shone around them; and they were
sore afraid. And the angel said unto them, " Fear not;
for behold I bring you good tidings of great joy which
shall be to all people. For unto you is born this day
in the city of David a Saviour, which is Christ the
Lord." Luke 2:8-11
"Oliver Elphick" <olly@lfix.co.uk> writes:
It no longer seems to be possible to refer to a table, which is an
ancestor of any other, in a referential integrity constraint.
bray=# create table junk (id char(10) constraint junk_id_person references
person(id));
NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY check(s)
CREATE
bray=# insert into junk values ('aa');
ERROR: SELECT FOR UPDATE is not supported for inherit queries
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.
regards, tom lane
I had meant to send this to the list as well.
------- Forwarded Message
Date: Fri, 22 Dec 2000 23:13:56 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>
To: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: [HACKERS] RI problem with inherited table
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. Change of permissions on a table propagates 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.
------- End of Forwarded Message
--
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
========================================
"And she gave birth to her first-born son; and she
wrapped him in swaddling clothes, and laid Him in a
manger; because there was no room for them in the
inn." Luke 2:7
Import Notes
Resolved by subject fallback