Re: OO Patch

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