Oliver Elphick wrote:
>
> Marten Feldtmann wrote:
> >> Hannu Krosing wrote:
> >> >
> >> >but as E can be an INT in one subclass and TIMESTAMP or VARBINARY in
> >> >other
> >>
> >> I don't think that should be allowed. It violates inheritance principles,
> >> since the types are not compatible.
> >
> > I see ... here's a person who has always programmed with typed
> >languages and now thinks, that this is the right definition .... it's
> >much more out there in the world. Open your mind and think about the
> >following:
> >
> > An attribute named "a" of "type" TIMESTAMP of an instance of a class
> >can be seen as a relation from this class to the class TIMESTAMP and
> >this relation is named "a".
> >
> > And if you're on the way to relations you're not far away to see,
> >that a relation is of course not limited to show to one specific class
> >... but perhaps to all subclasses also ... and this is not a
> >violation.
>
> However the example I was referring to talked of INT4, TIMESTAMP or VARBINARY.
>
> These are not subclasses but totally unrelated. Suppose you had
>
> parent (id char(2))
> child1 (a int4)
> child2 (a timestamp)
>
> and someone asks for
>
> select sum(a) from parent*
>
> since the types are incompatible, the answer would be nonsense.
MS Excel for example SUMs only things summable, by which logic in this
case
the sum would/could/should be sum of int4 colums.
In real world not all things are summable.
OTOH for schema parent (id char(2)) child1 (a orange) child2 (a apple)
select sum(a) from parent*
could yield "N apples and M oranges" or possibly "X fruits" if orange
and
apple were subtypes of fruit. Yes, really ;)
Or depending on how the sum() function is defined it could even be "Y
kg" .
---------
Hannu
