On 5 Sep 2002, Hannu Krosing wrote:
> Suppose you have a table CITIZEN with table-level constraint IS_GOOD
> which is defined as kills_not_others(CITIZEN). and there is table
> CIVIL_SERVANT (..) UNDER CITIZEN. Now you have just one table MILITARY
> (...) UNDER CIVIL_SERVANT, where you have other criteria for IS_GOOD....
This I very much disagree with.
In most object-oriented languages (Eiffel being a notable exception, IIRC),
you can't specify constraints on objects. But in a relational database,
you can specify constraints on tables, and it should *never* *ever* be
possible to violate those constraints, or the constraints are pointless.
So if I have a constraint that says, "no rows appearing in this
table will ever violate constraint X," and then you go and create
a way of inserting rows into that table that violate that constraint,
I think you've just made the database into a non-relational database.
I really don't want to break postgres' relational side for some
inheritance features of dubious utility. Constraints should be explicitly
removed from tables if they are no longer needed, not implicitly removed
through the creation of another table.
I think we should settle this point before going any further.
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