On Mon, 2002-08-12 at 17:30, Greg Copeland wrote:
> On Mon, 2002-08-12 at 10:39, Oliver Elphick wrote:
> > On Mon, 2002-08-12 at 15:00, Greg Copeland wrote:
> > > How exactly would you create an abstract base class for table type?
> >
> > CREATE TABLE abstract_base (
> > cols ...,
> > CONSTRAINT "No data allowed in table abstract_base!" CHECK (1 = 0)
> > )
> >
> > This assumes that the constraint is not inherited or can be removed in
> > child tables.
> >
>
> Why would I assume that constraints would not be inherited? Seems as a
> general rule of thumb, you'd want the constraints to be inherited. Am I
> missing something?
You are right, but I was stuck trying to think of a constraint that
would restrict the abstract base but not its descendants. Instead of
CHECK (1 = 0), I think we can use a function that checks whether the
current table is the abstract base and returns false if it is. That
would be validly heritable. (CHECK (tableoid != 12345678))
> Also, if I remove the constraint on the child table, doesn't that really
> mean I'm removing the constraint on the parent table? That would seem
> to violate the whole reason of having constraints. If a constraint is
> placed in an ABC and we find that we later need to remove it for EVERY
> derived class, doesn't that imply it shouldn't of been in there to begin
> with? After all, in this case, we're saying that each and every derived
> class needs to overload or drop a specific constraint. That strikes me
> as being rather obtuse.
Yes, it would be clumsy, and I think you are correct that constraints
should not be removable.
The inheritance model I am familiar with is that of Eiffel, where
constraints are additive down the hierarchy. That is, an invariant on
the base class applies in its descendants along with any invariants
added by the descendant or intermediate classes. That language has the
concept of a deferred class, which is the parallel of the abstract base
table we are discussing. A deferred class cannot be directly
instantiated. To do the same in the table hierarchy would require a
keyword to designate a table as an abstract table (CREATE ABSTRACT TABLE
xxx ...?). In the absence of that, a constraint based on the table
identity will have to do.
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight, UK
http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
======================================== "And he spake a parable unto them to this end, that men ought always to
pray,and not to faint." Luke 18:1
