Re: Re: [GENERAL] child table doesn't inherit PRIMARY KEY?

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Oliver Elphick <olly(at)lfix(dot)co(dot)uk>
Cc: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [GENERAL] child table doesn't inherit PRIMARY KEY?
Date: 2001-01-24 23:56:06
Message-ID: 200101242356.SAA18280@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Thanks. Done.

> 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(dot)Elphick(at)lfix(dot)co(dot)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
>
>
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-01-25 00:01:32 Re: FW: Postgresql on win32
Previous Message Bruce Momjian 2001-01-24 23:47:33 Re: Re: unixODBC again :-(