On Fri, 16 Aug 2002, Zeugswetter Andreas SB SD wrote:
> > Note that the other obvious way to solve this would be to store all of
> > the information inherited from the parent in the parent table, so that
> > you don't have to do anything special to make all of the constraints and
> > whatnot apply.
>
> Seems with above you are not able to constrain what qualifies for a
> supertable row, you would only be able to specify constraints that
> apply to all it's subtables.
Yes, that's the whole point. If I have a constraint on a table, I think
it should *never* be possible for that constraint to be violated. If a
subtable should not have constraint the supertable has, it shouldn't
inherit from the supertable.
To do otherwise breaks the relational model.
> The SQL inheritance is a class/subclass thing. All tables have
> instances (==rows) that are not (by itself) related. (Even if
> they happen to share all attribute values with another row of a
> supertable.) If you want that, then you need to resort to 3NF (or
> ROWREF's which iirc is another SQL99 feature).
As I understand it, SQL99 has the restriction that a row with the same
primary key appearing in a supertable and/or any of its subtables must
be the result of a single INSERT statement. Thus, SQL99 doesn't allow
what you're saying, if I understand what you're saying. (I'm not sure
that I do.)
Am I to take it that you think the inheritance should be inheritance
of type information only? That is, if I have supertable A and
subtable A', inserting a row into A' does not make a row appear in
A? If so, I've got not real problem with that at present, but it's
not what postgres currently does, nor would it conform to SQL99.
What do others think of this idea?
cjs
--
Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're
alllight. --XTC